[FEATURE] Display keybinding hints

[non-descriptive]

It's generally intuitive how bindings works, but still might be hard to navigate (how to trigger search bar when I read something). Many modern tui apps has hints what are keybindings on a current screen available. Also it's gonna be useful when features (like #161) pile up.
Here's for example how gitui and zellij show their hints.
.

Describe the solution you'd like
Add some bar that displays current frame's navigation keys, similar to gitui.

Checklist

• checked that this feature wasn't requested before in an issue
• read CONTRIBUTING.md

[Builditluc]

Hey @non-descriptive and thank you for your suggestion!
I really like the idea of having an overview of available keybindings. Because our keybinding-implementations currently are a mess, I have at the moment no clear idea of how to implement something like this (we would need to have a central place where the keybindings and in which context they are used are stored and somehow all views, even the ones from cursive, need to follow this).

I would put this for me personally a bit on hold until I've done the other features and #179 fixed but if you want feel free to give it a try!

[Ajlow2000]

Just chiming in with how I've interacted with tui tools and programs that provide keybind hints such as zellij:

Im not a huge fan of how zellij displays keybind hints due to how it uses screen space. (although I get that its more approachable). I would personally enjoy expose all the keybinds through an XDG_CONFIG_HOME config file. Maybe provide a super explicit default config that makes it clear what all the keybinds are-- bonus it also self documents how to change the keybinds this way.

Although I suppose these ideas dont stand in opposition to each other necessarily.

[non-descriptive]

Well, there are some general keybindings exposed as well as other params. But in some special cases it's hardcoded. But not sure whether it respects XDG env variables properly or it would require some aliasing.
And yes, obviously hints should has toggle of some sort whether its config or some command mode action.

[Builditluc]

Im not a huge fan of how zellij displays keybind hints due to how it uses screen space

What we could do is implement a way of hiding the keybinding hints (sort of like in zellij you can do zellij --layout compact to remove the hints). In the config file you could specify whether to show the hints.
I'm seeing two main ways of implementing such a system:

1. Specify the visibility of the hints in the config file
2. A keybinding that toggles the hints at runtime (although that would mean figuring out what to do when we have popups open, which certainly would be doable)

What we could also do is something like a general help menu that displays the currently available keybindings (depending on the current context). In there, we can also display some general tips on using wiki-tui or links to issues/guides.

[Builditluc]

I would personally enjoy expose all the keybinds through an XDG_CONFIG_HOME config file. Maybe provide a super explicit default config that makes it clear what all the keybinds are

We already generate a default configuration file if it isn't present, although this file doesn't include comments because we generate it by serializing the config.

I did a bit of research and found out that we can generate a default toml configuration with comments using toml_edit. This would require a restructuring of the configuratinon, but since that's planned anyways, its alright.

And you're right, the two ideas of yours don't stand in opposition so we can implement both of them.

[Builditluc]

Well, there are some general keybindings exposed as well as other params. But in some special cases it's hardcoded

That is because we're still using the cursive event loop, meaning that we cannot send custom events. Custom events are needed to enable us to rebind the keybindings (for example, the SelectView we're using for selecting lists has its keybindings hardcode. That's also why the vim actions implemented by #180 won't work for scrolling in lists).

I'm currently looking into implementing some kind of custom EventManager like ncspot does. That would enable us to not only define the keybindings in a central place (when translating the cursive keybinding events to our own), but also to have more advanced actions.

EDIT: This would also simplify implementing async stuff

[kemitix]

If you don't like giving up screen space for showing key binding hints, displaying a popup when the user pressed '?', would be one way of dealing with the problem. e.g. lazydocker does this.