Option to disable "navigate Block sub-menus with same key (1 .. 5)"

[TimShilov]

Is your feature request related to a problem? Please describe.
Recently the logic of 1-5 hotkeys was changed (here's the discussion: #3789).

I find this change frustrating and counter-productive. I would argue that this was a mistake and the previous defaults were superior in every way and would suggest reverting the change.

I believe this change is bad for both "typical users" and "advanced users".

Imagine a"typical user" that never switches tabs, so he/she is probably not "aware" of "Worktrees" tab or tabs in general. That user might hit "1" key while already being on the first panel and he/she will end up on the "Worktrees" tab which might be confusing and disorienting. 🤷‍♂️

"advanced users", on the other hand, suffer from unpredictable behavior.
The new behavior now forces such users to either:

1. Look at the screen to figure out which panel is active and whether or not anything needs to be pressed or not
2. To hit "2", realize that you was already on a correct panel and now you're on the wrong tab, then press "2" a couple more times until you get where you need to be.

IMO both cases are unnecessary mental overhead.

Before this change, pressing 2 always did the same one thing ("Go to branches panel, regardless of where you are") and pressing ] did the same one thing ("Go to next tab"). That's IMO straightforward and simple, each button does just one thing.
I'm really struggling to see why that was changed. What was the problem with that? 🤔

The OP said:

I'm always frustrated when I want to navigate to a sub-panel like Remotes or Worktrees and I have to Press '1-5' followed by ']' some number of times.

And I don't really see the problem with that. If you want to perform 2 different actions (go to panel and then switch tab) it is expected to have to press 2 different hotkeys, isn't it? Why would having to press 2 separate keys to do 2 separate actions be frustrating? 🤔

Describe the solution you'd like
I would argue that we need to revert that change because I'm really struggling to see how complicating a single hotkey is better than having 2 separate hotkeys each doing one predictable thing. This does not even result in less keypresses (I would argue it causes more due to the confusion).
At the very least, I would like to have an option to revert to previous behavior.

Separately, I would argue that the OP probably didn't wanted to be able to press 2 mutliple times, that was just a "workaround". I would assume that what he really wanted to do was to get where he needed faster or with fewer keystrokes, so why don't we address that instead of worsening defaults?
Can't we just have built-in or allow to create custom hotkeys to jump to "Worktrees" tab or "Reflog" tab from anywhere with a single hotkey?

Describe alternatives you've considered
Just like the OP of #3789, I don't believe it is possible to achieve with custom commands.

[TimShilov]

Btw, looking some more on this, I realized that [ and ] are not always doing the same thing. 😬

This is a separate issue of course but decided to note here as it is sort of related.
If you go to "Branches" panel and hit "Enter" to look at commits of a specific branch - hitting [ or ] just goes one level up (just like hitting Esc does). This is so weird and unexpected IMO. 🫣
Why would hotkeys described as "Previous tab" and "Next tab" in the help do something other than that? The commits list doesn't even have tabs, so I would expect them to do nothing.

[stefanhaller]

O wow, that's a strong opinion. 😄 I don't agree that we should revert the original PR, because some people want the behavior. We should just make it optional, and we have a PR already to do that.

It is being discussed here, the only open question is what the default for the new option should be. Judging from your strong reaction, I suppose it should be off by default.

This is a separate issue of course but decided to note here as it is sort of related. If you go to "Branches" panel and hit "Enter" to look at commits of a specific branch - hitting [ or ] just goes one level up (just like hitting Esc does). This is so weird and unexpected IMO.

This was mentioned here. I agree that this is probably unintended, and could be called a bug, but I happen to really like the behavior and use it often, so I would vote for not fixing the bug. 😄

[jesseduffield]

Thanks for making such a strong case. I agree. One of Lazygit's main strengths is its support for muscle memory and having these navigation keybindings behaviour depend on the view state means users can't depend on muscle memory to perform tasks.

[TimShilov]

Guys, I can swear I have searched for existing issues before creating this one. Sorry for creating duplicate. 😅
Thank you for the swift response and provided links. I'll definitely subscribe to the PR and will be eagerly waiting for the new option to be merged. 🙏

Below is my humble opinion on the topic just to discuss it a bit broader, but I consider the issue a duplicate so I'll close it.

---

I don't agree that we should revert the original PR, because some people want the behavior. We should just make it optional, and we have #3927 already to do that.

The fact that people want the behavior is perfectly fine and it is great that you guys are open to suggestions and improvements! 👍

I can understand and sympatize people who want the changed behavior. What I can't agree with is the implementation and "people want it so let's do/keep it" approach. That's why I suggested to revert the PR. Not because it's not worth giving people what they want, but because I think the implementation is not good and can be reconsidered and implemented better, giving people what they want without sacrificing simplicity!

It is up to you of course, but IMO this is a very sketchy path with tons of un-trivial questions, uncertainty and requirement to "dance around" subjective requests and I, personally, wouldn't want to step on that path if that was one of my projects. I strongly believe that "discipline is freedom". 🙃

Lazygit have now allowed people to use 22 to switch to panel 2 and then navigate one tab to the right.
What happens if tomorrow someone will come up with an equally reasonable request to change it to something like "expand the panel to full screen" or "exit from nested menu like Esc and [ do" when 22 is pressed. Or what if someone tomorrow ask to allow switching tabs with left and right arrows which seems more intuitive and reasonable. What to do then? Complicate the hotkey even more and have more "modes" for the same hotkey? Tell the new requesters that "sorry, it is already taken, nothing we can do here" even though both requests are equal? Introduce breaking changes and disrupt people's workflows again by replacing the previous behavior with the new one? How to make the changed behavior discoverable so people are aware of it? How to document it in the help without listing 3 different actions the same key might do and how to understand when and how lazygit will handle them?

As I've mentioned above, I doubt that what people really want is to press 22 instead of 2]. People just want to do things faster and I'd bet they would be willing to consider alternative solutions which would be simple and straightforward for both users and maintainers.
If people want to have different workflows - I'm all for letting them customize and improve things.
However, I would argue there should some limitations. Just a couple example limitations of the top of my head that I would find reasonable:

1. A global hotkey always does one thing (unless overriden explicitly in the config).
2. Prefer adding more flexibility to custom commands instead of adding more options (unless it is for something very popular amongst users).