Using (layout +bepo), (evil +everywhere) and magit: in magit buffers, including e.g. magit status buffer, k is bound to evil-previous-line as if no remapping happened.
What did you expect to happen?
(layout +bepo) remaps keybindings for bepo layout keyboards. Combined with evil-mode, this means keys hjkl are remapped to bepo’s homerow ctsr.
Therefore in magit, k (instead of s) should be bound to magit-stage.
Steps to reproduce
Enable :input (layout +bepo), :editor (evil +everywhere), and :tools magit in init.el
Open the magit status buffer in some git directory.
Press k while the point is on some file, or press SPC h k k to observe that k is bound on evil-previous-visual-line.
Additional information
Using which-key to display magit-status-mode-map shows that k is bound to magit-stage as expected. However, inspecting the same keymap with helpful-variable shows 3 keybindings for <normal-mode> k: one on evil-previous-line and two on nil (which is kind of confusing to me).
Thanks for the report, I’ll try to take a look at some point next week. As you can see by the size of the comments, the magit section has already given me a few headaches. I think I’ll actually need to remap manually k and j to fix it, but unsure yet.
Just to rule out something else spicy going on, can you try to hit gk on a file, and tell me whether that stages it or does nothing ?
I’ll take advantage of this message to say that I’m looking for a successor to maintain the bepo module; mostly because I’m using Optimot now, and I think I won’t do so many remappings for optimot too. At least I don’t think so yet.
Thanks for the quick reply. I was wondering whether you were also running into this issue.
gk does not stage files (it is bound on magit-section-backward-sibling). In the meantime, I use SPC g S as a workaround.
I would gladly help maintaining the module, but I’m afraid I lack the elisp proficiency to do so. I can more or less make sense of the simpler parts of the code, but anything more is beyond me.
On the original issue report from a Colemak user here
Looks like the list of extra keymaps to rotate outside of evil-collection hook can be reduced, and I need to check the ««new»» commits in evil-collection to see how the change affects the module
Thank you for the fix. I didn’t extensively test the PR, but I can at least confirm that the issue is fixed, and I didn’t meet any unexpected side-effect.
Edit: I did see the message appear without the layout module active, but only once and without any incidence on performance. But this might not be as relevant as I initially thought.
There was a lot of changes recently regarding the way packages are loaded (and the CPU spikes are coming from Emacs running native compilation “just in time” when you first require a module rather than “ahead of time” during a long last step of doom sync/up). I’ll try to keep an eye on this but I really think that this issue is unrelated to the bépo change (which really only affects magit as far as I remember)
I did more testing (I am not that comfortable with Emacs lisp, unfortunately) you are correct, the commit itself did not cause the issue. I drop the commit and the issue was still there. So I guess the ongoing refactoring is responsible
I’ll try to do more digging when I have time, hopefully the issue will get resolved as @hlissner is (I’m guessing) still busy refactoring lots of parts.
I’m also having this issue. Disabling the layout module make emacs usable (well, except for muscle memory). I first reported this on the discord: Discord and there was some discussion there, but not much crucial information.
