[REQUEST] add more details to :debug mappings and/or provide an additional command that shows all bindings

[dontlaugh]

Feature

Information about current key mappings is available from :debug mappings. See #3383

However, I think we should work towards printing some more info here. Ideally I'd like to see

[MODE] [KEYBINDING] [COMMAND] [DOCSTRING]
                     `--new     `-- show me a default, if possible

Note: or maybe even a reconstruction of Kakscript that creates the mapping...

Here is the output of :debug mappings from a recent session. I am running master 8870c7e

Click here for output

*** This is the debug buffer, where debug info will be written ***
Mappings:
 * normal <left>: 
 * normal <right>: 
 * normal <down>: 
 * normal <up>: 
 * normal <s-left>: 
 * normal <s-right>: 
 * normal <s-down>: 
 * normal <s-up>: 
 * normal <end>: 
 * normal <home>: 
 * normal <s-end>: 
 * normal <s-home>: 
 * normal m: 
 * normal n: 
 * normal e: 
 * normal i: 
 * normal M: 
 * normal N: 
 * normal E: 
 * normal I: 
 * normal k: 
 * normal K: 
 * normal ': 
 * normal h: 
 * normal H: 
 * normal l: 
 * normal L: 
 * goto d: definition
 * goto r: references
 * goto y: type definition
 * goto m: start of line
 * goto n: end of buffer
 * goto e: top of buffer
 * goto i: end of line
 * user s: List buffile siblings in repl
 * user /: comment line (toggle)
 * user c: command prompt
 * user i: select within
 * user w: write buffer
 * user q: quit
 * user Q: quit without saving
 * user H: c/c++: swap between header and impl
 * man g: Jump to a man page using selected man page link
 * man j: Go to next man page link
 * man k: Go to previous man page link
 * man m: Look up a man page
 * lsp a: show code actions for current position
 * lsp c: show language server capabilities
 * lsp d: go to definition
 * lsp e: list project errors, info, hints and warnings
 * lsp f: format buffer
 * lsp h: show info for current position
 * lsp H: show info for current position in a scratch buffer
 * lsp i: go to implementation
 * lsp j: list outgoing call for function at cursor
 * lsp k: list incoming call for function at cursor
 * lsp l: apply a code lens from the current selection
 * lsp o: search project symbols
 * lsp n: find next error
 * lsp p: find previous error
 * lsp q: exit session
 * lsp r: list symbol references
 * lsp R: rename symbol
 * lsp s: jump to document symbol
 * lsp S: list document symbols
 * lsp v: select inner/outer nodes
 * lsp V: select inner/outer nodes (re-use previous call)
 * lsp y: go to type definition
 * lsp [: show hover for previous symbol
 * lsp ]: show hover for next symbol
 * lsp {: goto previous symbol
 * lsp }: goto next symbol
 * lsp 9: show hover for previous function
 * lsp 0: show hover for next function
 * lsp (: goto previous function
 * lsp ): goto next function
 * lsp &: lsp-highlight-references
 * lsp =: format selections
 * lsp-selection-range j: select inner node
 * lsp-selection-range k: select outer node
 * lsp-selection-range b: select innermost node
 * lsp-selection-range t: select outermost node

In my opinion, there are some issues with the current output:

1. It only seems to show mappings that have been modified from the defaults
2. For remapping of builtin modes, like normal mode movement, I don't get any descriptions of the mappings unless I explicitly provide a docstring in my mapping
3. I don't see the command I'm mapping to, which would be useful

Number 1 is an issue of discoverability. Kakoune's interactive documentation is very good, but it is also quite expansive. :doc keys is 700 lines of asciidoc, and that's not the only place keystrokes are defined. I think printing all the default bindings as well as whatever is currently dynamically loaded from kakrc/plugins would be really helpful.

As for number 2, I understand why it happens. Here's my remapped movement (I use Colemak-DH layout):

map global normal m h # left
map global normal n j # down
map global normal e k # up
map global normal i l # right

I do not provide a -docstring. But what I have is a reasonable configuration, I think, because what's interesting about Kakoune's command language is that h literally means "move left". It seems like there is enough information at runtime to recover the original docstring, or perhaps for this class of commands the docstring could be preserved somehow, since mapping a key to h will always move left?

For number 3, here's an example from my config that gets dynamically loaded for Go code

map buffer user 'f' ':format-buffer<ret>' -docstring 'go: run gofmt'

... and :debug mappings prints this

 * user f: go: run gofmt

What if instead it printed something like this?

 * user 'f' ':format-buffer<ret>': go: run gofmt

[Screwtapello]

It would definitely be helpful to have the right-hand-side of the mapping included in the debug output, even if only just for mappings that do not include a docstring (which is most of them).

It only seems to show mappings that have been modified from the defaults

Technically, that's what a mapping is: a modification from the defaults. h isn't mapped to the "move left" command, it is the "move left" command.

On one hand, it might be nice to have better visibility on the current state of the system; on the other hand, Kakoune tries pretty hard to discourage people from building abstractions - all the mappings in your configuration should be ones you put there yourself, not introduced by a plugin.

[dontlaugh]

h isn't mapped to the "move left" command, it is the "move left" command.

Indeed, this is what I was trying to express. It's one of the more mind-bending strokes of genius of this editor.

Technically, that's what a mapping is: a modification from the defaults.

True. And :debug mappings is already useful enough to show what's been modified. There should be a way to do that, come to think of it.

So maybe showing all the bindings might be best accomplished as an additional debug command called :debug all-keys or similar.

The display of the right hand side of the mapping is another little enhancement that would apply in either case.

[dontlaugh]

Maybe the best output would be to dump the mappings as valid kakscript? Just a thought.

[krobelus]

for learning default mappings I used this command though it leaves some things to be desired (only works for normal mode).
I imagine it would be nice if there was a mechanical way to find out the meaning of a single key (whether mapped or not), something like Emacs' C-h k but it's not clear how it should work. I don't think :debug mappings is necessarily something for everyday use.
I agree the rhs should probably be included, should be easy to do

[dontlaugh]

I agree the rhs should probably be included, should be easy to do

If that's easy to do, that would probably be the highest impact change mentioned, even if the other things can't be done right now (output unchanged defaults, add docstrings to everything).

I imagine it would be nice if there was a mechanical way to find out the meaning of a single key (whether mapped or not), something like Emacs' C-h k

That would be great! It also sounds like something that could be made difficult due to implementation details I don't really understand.

Since that's a really specific change, I will open a separate issue for just adding rhs to :debug mappings. This issue can remain open and we can keep brainstorming on improvements to interactive feedback on current key mappings. #5152