1. Frank Fischer
  2. evil
Issue #129 invalid

Unable to load "evil-surround.el" with the 10320dc

York Zhao
created an issue

I have the following 3 lines in my .emacs.

{{{ (require 'evil) (evil-mode 1) (require 'surround) }}}

I set the `debug-on-error' to t and started emacs with emacs --debug-init, and got the following error.

{{{ evil-define-key(operator (keymap) "s" surround-edit) byte-code("\301\302\303\304#\210\305\306\307\310$\210\305\311\307\312$\210\305\311\313\314$\210\315\316!\207" [surround-mode-map put global-surround-mode-cmhh definition-name global-surround-mode evil-define-key operator "s" surround-edit visual surround-region "S" Surround-region provide surround] 5) require(surround) }}}

If I don't load `surround' I got no problem on start up.

EDIT: Before swithing to the last version I was using 8b4fb18 without having this problem.

Comments (9)

  1. Frank Fischer repo owner
    • changed status to open

    I've just downloaded the latest surround.el and it works fine here. The error suggests that your surround.el has been byte-compiled and perhaps that byte compiled version does not work well with the latest evil. Please try to recompile surround.el (or better remove surround.elc first without recompilation, and load the source file directly - this may give more helpful error messages).

  2. Michael Markert

    Could reproduce with evil HEAD and stale byte-compiled evil-surround. After recompiling evil-surround the problem is solved.

    I think the problem was caused by c58744b Merge `evil-define-key' and `evil-declare-key' as it changes the code for `evil-define-key` that evil-surround uses.

  3. York Zhao reporter

    Thanks guys, recompiling "surround.el" worked. Actually, not only does the file "surround.el" need to be recompiled, but also, everything that uses `evil-define-key' have to be recompiled in order to be able to work with the version of Evil that introduced changes to `evil-define-key'. I believe this is because that `evil-define-key' used to be defined as "defun" but is now a macro.

    This reminded me of one thing that after upgraded Emacs system itself, it would be better to recompile everything just in case which would be a huge huge pain. What are your thoughts about this?

  4. Michael Markert

    > What are your thoughts about this?

    Well, what do you mean? An announcement "commit xyz will break your config" would have been nice. But this is one of the dangers of using a dev-version ;)

    If you mean the byte code: Well using no byte-code solves byte code problems as well. Besides that it's getting thin ..

  5. York Zhao reporter
    Well, what do you mean?

    Suppose that you updated your Emacs, it's better to recompile all the third party packages you are using to avoid similar problem as the case in `evil-define-key'.

    What I can think of is to create a Makefile or script to rebuild all the third party packages I'm using after updated Emacs. However, if a package doesn't come with it's own Makefile I will need to write one for it. Yet another approach is to always use "Make install" supplied by the package (if it has one) to install the package to Emacs "lisp/" or "site-lisp" directory so that compiling Emacs might recompile these packages I think. What I meant was that I wanted to know if you guys have better way to handle this.

    Sorry for being slightly off-topic.

  6. Log in to comment