(layout +bepo) does not properly remap k in magit

What happened?

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

  1. Enable :input (layout +bepo), :editor (evil +everywhere), and :tools magit in init.el
  2. Open the magit status buffer in some git directory.
  3. 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).

System information


Loading data dump...

Hello,

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.

No worries about the module, I’m just getting the message out there.

Don’t mind this message, I’ll use this post as a «Notes» pad to remember to read things.

Apparently jojojames made changes mid April

  1. On the fix of evil-collection-translate-key here
  2. 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

You can use the branch of this PR to fix the issue. I tested it only lightly so:

  • it should fix your issue with k not being bound correctly.
  • there’s no guarantee that no other issue appeared, but I’m hopeful it should be fine.

To check out an unmerged PR you can do git fetch origin pull/6746/head:bepo-magit && git checkout bepo-magit in the directory where you cloned GitHub - doomemacs/doomemacs: An Emacs framework for the stubborn martian hacker

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.

Hi, I think the last MR introduced regressions.

When enabling the bépo layout in a fresh configuration, after a while (or I can reproduce it quite frequently with M-x) I get an error:

['org' was already loaded by the time lang/org loaded, this may cause issues].

The issues in my case is an Emacs instance not responsive and my CPU usage is increasing by intermittence.

Here’s my doom/info

generated  Sep 17, 2022 02:12:25
system     NixOS 22.11.20220915.454887a (Raccoon) Linux 5.19.8 x86_64 x
emacs      28.2 ~/.config/emacs/ -> ~/.config/emacs/
doom       3.0.0-pre PROFILE=_@0 HEAD -> master 811c18ca 2022-09-16 19:20:45 +0200
           ~/.config/doom/ -> ~/.config/doom/
shell      /run/current-system/sw/bin/zsh
features   CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON LIBOTF
           LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NATIVE_COMP NOTIFY INOTIFY
           PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS X11 XAW3D
           XDBE XIM XPM LUCID ZLIB
traits     gui server-running envvar-file
modules    :input (layout +bepo) :completion (vertico +icons) :ui doom :editor (evil
           +everywhere) :tools magit :os tty :lang org :config (default +bindings
           +smartparens)
elpa       vterm tablist sqlite pdf-tools nadvice let-alist

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.

Hello,

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 :thinking:

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.

It should have been fixed in Doom itself now. Try to upgrade now (you need to land past fix: $DOOMDIR loading twice and too early · doomemacs/doomemacs@b7b66e6 · GitHub ) :slight_smile:

1 Like

Thanks for the heads-up! It seems to be working now :slight_smile:

Fixed for me too. Thanks!