Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

spacemacs/init-evil rebinds K after loading buffer #2909

Closed
jschaf opened this issue Sep 7, 2015 · 11 comments
Closed

spacemacs/init-evil rebinds K after loading buffer #2909

jschaf opened this issue Sep 7, 2015 · 11 comments

Comments

@jschaf
Copy link
Contributor

jschaf commented Sep 7, 2015

I rebound K in a private layer to move up 5 lines. After I load any buffer, spacemacs rebinds K to spacemacs/evil-smart-doc-lookup.

Is there a way to prevent that from happening?

@person808
Copy link
Contributor

Try wrapping your code with (with-eval-after-load 'evil some-code)

@jschaf
Copy link
Contributor Author

jschaf commented Sep 7, 2015

I have a function my:evil-keybindings that sets up my evil config. I created a private layer to do most of my customization. I tested running my:evil-keybindings a in a couple ways. Here was the order in which customizations were executed from earliest to latest:

  1. Private Layer - bare call - (my:evil-keybindings)
  2. Private Layer use-package :config - (use-package evil :config (progn (my:evil-keybindings)))
  3. Private Layer with-eval-after-load - (with-eval-after-load 'evil (my:evil-keybindings))
  4. Spacemacs use-package 'evil :init in ~/.emacs.d/spacemacs/packages.el
  5. dotspacemacs/user-config in .spacemacs

I don't understand why 2 & 3 run before 4. That doesn't make sense to me.

@person808
Copy link
Contributor

In your private layer add this to your packages.el (assuming evil is already in the <layer>-packages variable):

(defun <layer>/pre-init-evil ()
  (spacemacs|use-package-add-hook evil
    :post-config
    (progn
      (my:evil-keybindings))))

@syl20bnr
Copy link
Owner

syl20bnr commented Sep 7, 2015

I don't understand why 2 & 3 run before 4. That doesn't make sense to me

You are right, this is a big bug, going to fix it ASAP, thank you !

@jschaf
Copy link
Contributor Author

jschaf commented Sep 7, 2015

@person808 the pre-init-evil worked, thank you.

@syl20bnr
Copy link
Owner

syl20bnr commented Sep 7, 2015

Indeed but it should not be necessary, OTOH what @person808 told you is the correct way to override lazy loaded settings, so always good to know :-)

@syl20bnr
Copy link
Owner

syl20bnr commented Sep 7, 2015

@jschaf Actually there is no bug at all :-) Did you put your evil stuff in a pre-init function ?
Can you paste here your configuration layer as well as your dotspacemacs-configuration-layers variable ?

@jschaf
Copy link
Contributor Author

jschaf commented Sep 8, 2015

The evil stuff was not originally in a pre-init function. I tried use-package :config and with-eval-after-load.

I'll link to my code:

https://github.com/jschaf/dotfiles/blob/master/spacemacs-layers/joe/packages.el
https://github.com/jschaf/dotfiles/blob/master/home/.spacemacs

joe is my private layer.

@syl20bnr
Copy link
Owner

syl20bnr commented Sep 8, 2015

Ok I see, now all keybindings.el files are called before loading the packages.el files of the layers, this is why your bindings were overwritten. keybindings.el should not define bindings for packages, this file is here to provide a place where to put key bindings for stock emacs functions.

The order of loading is (from a file point of view):

  • for all layers: load funcs.el
  • for all layers: load config.el
  • for all layers: load keybindings.el
  • for all layers: load packages.el

I think that we should remove funcs.el and keybindings.el to keep only config.el which is called before loading any packages.el.

@jschaf
Copy link
Contributor Author

jschaf commented Sep 8, 2015

I think that we should remove funcs.el and keybindings.el to keep only config.el which is called before loading any packages.el.

I agree. It's confusing to figure out what goes where. I would add a paragraph to the documentation on the precise order that the files are loaded and guidelines for how to separate functionality between the files.

@TheBB
Copy link
Collaborator

TheBB commented May 31, 2016

I think this can be closed.

@TheBB TheBB closed this as completed May 31, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants