Doom-emacs: Custom keybindings stopped working since 0425724

[dariooddenino]

If I checkout any commit starting from 0425724 my custom keybindings are completely ignored.

[AloisJanicek]

Since you don't mentioning more serious issues with your setup like that it doesn't even successfully compile or throwing some error on startup, I will base my advice on my recent experience with basically same problem.

1. Try wrapping your map! call(s) with add-hook! 'after-init-hook like this:

(add-hook! 'after-init-hook
  (map! ...))

1. Or _alternatively_ reorganize your init files like this:
2. ~/.emacs.d/init.el:

...
(doom! :feature
             ...
       :completion
            ...
       :ui
            ...
       :tools
            ...
       :config
       (default +bindings +snippets +evil-commands)
       (private) ;; <= load it AFTER default module
 )
...

• ~/.doom.d/init.el:

...
(doom! :lang
             ...
 )
...

It is important to ensure that (default) module loads before (private) and after evil stuff (so at least :feature)

[dariooddenino]

I'm not sure about the init files reorganization. Right now I have these inside ~/.config/doom. Is it incorrect?

If I wrap map! with that add-hook!, the key mappings stop working on older commits too :(

[AloisJanicek]

How your ~/.emacs.d/init.el looks like?

Because if your have (doom! :config (private)) in /.emacs.d/init.el and (doom! :config (default)) in ~/.doom.d/init.el, (like you have), default module (from ~/.emacs.d/modules/config/default) loads after your private module (aka ~/.doom.d/) and interferes with your keybindings.
You want to load your (private) module after (default +bindings +snippets +evil-commands) .

My suggestion about reorganization of your init files is simple: For now move your whole (doom! ) call back into ~/.emacs.d/init.el (like it is suggested at example.init.el )and try to compile and run Doom Emacs and report back if your issue with key bindings is still there.
(For now don't have (doom! ) call at all in your ~/.doom.d/init.el)

[dariooddenino]

Yes, that must be the case, as my ~/.emacs.d/init.el is just: (doom! :config (private +xdg)).
The weird things are that using add-hook! 'after-init-hook didnt' solve it, and it was working anyways until commit 0425724 with the config I linked :/

[AloisJanicek]

(add-hook! 'after-init-hook (map! ... )) was suggested to me by Henrik on Doom's discord channel yesterday - I din't tried it though - I prefer to move (doom! ...) call back to .emacs.d/init.el for now until I give my config.el some more cleaner structure.

[hlissner]

It's not technically misbehavior (it's simply module load order), but I can see how it's undesirable.

@AloisJanicek @dariooddenino I know a simple fix for this that I can incorporate directly into the :config private module, but please try it out first:

In ~/.emacs.d/modules/config/private/config.el, change:

-(load (expand-file-name "config.el" +private-config-path)
-      'noerror 'nomessage)
+(add-hook! 'after-init-hook
+  (load (expand-file-name "config.el" +private-config-path)
+        'noerror 'nomessage))

This should ensure that your private config.el loads as late as possible (which I think is sensible behavior).

[AloisJanicek]

@hlissner, it works for me.
Now I can have ~/.emacs.d/init.el as minimal as:

(require 'core (concat user-emacs-directory "core/core"))
(doom! :config (private))

and rest of stuff in ~/.doom.d/init.el.
Really cool, Thank you!

[dariooddenino]

Works perfectly for me too :)

[hlissner]

Alright, the fix is now in develop, so I'll consider this reoslved. I'll leave this open until it hits master.