"<enter>" is not displayed in the keybindings panel

[zzJinux]

Describe the bug

<enter> is not displayed for the item that describes the keybinding bound to the enter key in the keybindings panel.

To Reproduce

Steps to reproduce the behavior:

1. Go to any panel having the "enter" bound to some command
2. Open the keybindings panel

Expected behavior

<enter> is displayed for the item it is supposed to

Screenshots

Version info:

• commit=, build date=, build source=Homebrew, version=0.55.0, os=darwin, arch=arm64, git version=2.50.1
  • The master version also reproduces.
• git version 2.50.1

Additional context

Add any other context about the problem here.

Note

Please try updating to the latest version or manually building the latest master to see if the issue still occurs.

[stefanhaller]

While I admit that this might be confusing, this was actually changed on purpose (see b3a3410), although I admit I did that only for when you remap confirm to something other than "enter". But it makes some sense for "enter" too; after all, pressing "enter" in the keybindings menu invokes whatever command is selected, and not the "Switch to recent repos" command.

Any ideas how to make this less confusing would be appreciated.

[zzJinux]

Leaving it empty has a downside, clearly. No normal user would guess what that really means. It's visually natural to interpret that the item does not have a keybinding at all (or am I missing something?). But I admit it may be less surprising than showing <enter>.

I understand the "conflict" you stated. It's rooted in the fact that there is another layer for keybinding, the confirmation. At least I got to know what's going on; the problem still exists for others. It's really a hard problem, and I also can't come up with a clever solution here.

[stefanhaller]

Thinking about it more, I think we should exclude the keybindings menu from this logic of hiding keybindings that conflict with the confirmMenu key. See #4880 for rationale.

[Aethereal-Wraith]

This bug also affects the Stage lines / Collapse directory local option in the [2]Files menu.

I have not followed lazygit's development so I am not fully up to date on the impetus behind the commit you linked but after reading through the commit and playing around on my setup I can see that you wanted to prevent this scenario:

• the user presses ? to look for the keybinding for the action they want to take
• they see <enter> listed as the key-bind for it's normal action (eg Switch to a recent repo or Stage lines / Collapse directory)
• the user presses <enter>, expecting it to perform the listed action
• lazygit instead executes the currently highlighted action instead of the specific action
  This is unexpected for the user but intended behaviour in the ? keybindings menu; because in that menu it changes functionality from being a keybinding to simply selecting whichever key/action pair is highlighted. As a new user (only been using every now and again for a month or two), I didn't realise this functionality existed. I thought that the ? menu was more of a cheat-sheet/documentation for keybindings, like in Google Docs (don't know why that was the first example that came to mind seeing as I haven't used it in years). It really feels wrong for me that there is a blank space where a keybind should be in this menu. My original opinion was that reverting the change and just letting there be a bit of friction in this area was preferable to leaving the user guessing how to access the desired action. I think it is very reasonable to imagine a user who both did not know you can select actions directly from the ? menu and that could not guess that means <enter>.

They say when receiving feedback, listen to what the user/reviewer/etc says is the problem, ignore their suggestions for a solution. That being said, I'm going to suggest a possible solution, although I'm sure it'll be worse than what you real programmers will come up with.
After more thoughtfully considering why this change was implemented, I agree that this should be the intended functionality and that <enter> should not appear in the ? menu if it is the confirmMenu key. Instead, some other keybinding should appear there, i.e. my solution would be to identify every keybinding that uses <enter> and try to find some suitable replacement binding. My off-the-top-of-my-head suggestion for @zzJinux 's original screenshot would be to change the key-bind to r for Switch to a [r]ecent [r]epo. My suggestion for Stage lines / Collapse directory would be h or l, though I'm much less confident in that choice than my previous suggestion. My reasoning is that h/l is the vim binding for left/right, and file tree GUIs often show collapsing a tree as a little arrow going from pointing down to pointing horizontally. Additionally, h is for git [h]unks and l is for Stage [l]ines / Co[l]lapse directory.

Sorry for the nuclear bomb of text, I have trouble being concise and didn't want to leave an unhelpful issue comment.

[stefanhaller]

@Aethereal-Wraith Thanks for the input. Your analysis of the problem is spot on, but your suggestion for solving it isn't. 😄

I decided that the cheat-sheet character of the keybindings menu is more important than the functionality to trigger commands by their keybinding while the menu is open. See #4880 for the fix.