Allow to override keybindings about neogit

[TimUntersberger]

I added functionality for overriding mappings. Please look at the README for further information.

I will not close this issue until all popups support this.

Missing popups:

• Help (Should be generated from status mappings I guess?)
• Push
• Pull
• Branch
• Commit
• Log
• Stash

[TimUntersberger]

This is not possible yet, but I will add this later today.

[hadronized]

Thanks a lot for the rapid feedback! 🙇

[TimUntersberger]

After thinking about it some more, I'm not too sure whether supporting remappings of popup windows is really needed.

@RianFuro any thoughts?

[RianFuro]

@TimUntersberger It's tricky, right? Magit has this "convention over configuration" mentality, which kind of clashes how stuff is usually done in vim-space.
I think you're right; we don't actually need remappable controls in popups as far as keyboard layouts are concerned, since all that's allowed in there is pressing the described shortcuts.
Beyond needing though, this becomes a discussion of how much we want to move away from that convention over configuration mindset. I don't think there's a clear answer to that; I'd likely not implement this myself since I see no need, but if somebody would feel strong enough about it to contribute the functionality, I wouldn't be entirely against merging it.

[hadronized]

The idea is that I’m not using a qwerty keyboard, I’m using a bépo layout, and my j and k keys are t and s. So if I want to move the cursor up, I press s.

I would definitely like a way to override pop-ups keybindings as it will be a nightmare otherwise. The only other solution I have otherwise is to fork and modify the Lua code, which is clearly not ideal.

[RianFuro]

@phaazon you're not really moving the cursor (or doing anything but using the presented keybindings for that matter) in the popups.
Maybe we need a better naming scheme here 😅 when we say popup we mean the prompts that just show you the available options and keybindings, not the status or log buffer and such.

I'm just using a regular qwerty layout though, so maybe I'm overlooking something here. Can you elaborate what problems you would have in the prompt-style popups? I realize that cursor movement and other default bindings are different for you, but I don't think any of those apply in those buffers (or make no sense to use anyway)

[TimUntersberger]

@phaazon the way I think about the popups (or "transient commands" in magit) is a visual representation of key chords.

For example:

You could add a mapping for pushing to upstream like Pu which does exactly the same (Actually in magit the popups only appear after some delay after pressing P).

Now one advantage of popups is that you don't have to remember ANY keybindings except the popup keybindings, because you always have a list of available commands. Another one is that these make it possible to realize something like the options and switches you can see in some popups (like the log popup), which would be impossible to make usable with normal keybindings.

And don't get me wrong if there really is a need for being able to customize them, then we will implement it. Implementing this is really easy, because you just have to do the same thing I did for the status buffer except for the popups themselves (which is really tedious to maintain/create imo)

[hadronized]

Navigating hunks / files does move the cursor, though.

[RianFuro]

@phaazon That's where the difference is. We're completely on board with allowing mapping customization for the status- and log-buffer (and every subsequent navigatable buffer). But as for the "shortcut" buffers (like when you press c for the commit popup or Z for the stash popup from the status buffer), there's really no need to customize anything, as they just offer you some mnemonic bindings and a way to set options and don't allow (or at least meaningfully react to) any other input.

[hadronized]

Ah for the transient popups, I totally agree, it even makes more sense to keep semantic keybindings — i.e. ce for commit extend, etc.

[TimUntersberger]

@phaazon is this fixed for you?