Keybinding UI editor

[JosephTLyons]

Is your feature request related to a problem? Please describe.
It isn't always super easy to work with the keymap.json. Sometimes I have no issues, other times, I'm totally lost on why something isn't working. There is an issue open for validation of config files, but I'm starting to think a keybinding user interface would be a much nicer experience.

Describe the solution you'd like
A panel (maybe something that just opens up in a tab?) that has the following setup (description could be skipped):

Action	Description	Keybinding
Go To Line	Moves Cursor to Line	alt-g

The only editable area would be the Keybinding column. At a minimum, the user could just type in the keybinding, but having it capture the binding would be icing on the cake.

Some additional considerations:

• Ability to detect when there's a collision and prevent users from saving it until it is resolved.
  • Currently, if you have keybinding A registered to some action, adding a new keybinding B for that actiondoes not de-register keybindingA`, so you end up with 2 keybindings doing the same action and you can't de-register the original. Having the UI enforce that all bindings must be unique would solve this.
• Ability to de-register bindings that they'd never use that they just want to get rid of
• Ability to restore default keybindings

[iamnbutler]

Have you seen any good implementations of this? Personally I find VSCode's settings ui abysmal, and dread any time I have to use it.

I feel like the closest positive experience I've had is remapping UIs in games.

[endigma]

I've never had any issues with VSCode's keybind editor, it's not in the normal settings area. I like the approach taken with binding keys to commands rather than commands to keys like "down" => "cursorDown" and also a million other things.

There is a UI specifically for this in VSCode, I think it works well.

[admsmz]

Hi everyone. I made a mockup of a keybinding interface that I believe would be an improvement on the status quo. Basically the idea is to use a table rather than a list. Here's a screenshot:

Using two dimensions means you can visualise where approximately a keybinding is based on theme, if many similar keybindings are grouped close together. At least, that's how my mind works. Ymmv.

[JosephTLyons]

Im wondering if we can ship something smaller in the interim - just a modal that displays the keys being held, allowing for copying and pasting into the clipboard so you can paste it into your keymap.json file.

[samholmes]

VS Code's solution is good, but what would be great?

What if instead of a big ol' table, we got an interactive Keymap UI? Instead of opening a settings screen and tinkering our keymaps only to return back to our flow state we could interactively add keymaps without breaking flow state; how could this be done? Here's a proposal.

At anytime in the editor, one could activate the Keymap UI with a single keybinding (say it's cmd+shift+:, or cmd+shift+? or something not taken). This will bring up a palette like the command palette, showing all the key maps for the current context. From this UI, there is an focused input which a search term for a particular command can be found (exactly like the command palette). Once a command is found, the user can press the tab key to enter a keybinding text. Once they've entered the keybinding text, then can either press tab again to go to change the context, or press enter/return to submit the new keybinding to the list. At any time, esc key will exit the Keymap UI.

This Keymap UI palette (or sidebar?) could visually contain a sorted list by bindings with all keybinding matching the current context, and then sections with lists for transitive context. The sections are sorted by the context with the highest match to the current context. This will help aid in discovering which keymaps are available under the current context and any transitive matches. In addition to discovering current keymaps, it will help with discovering what actually exists by just getting the editor in the particular desired state. Some tooltips could help aid in explaining the contexts shown in this UI to understand why they're present.

I like the idea of having a Keymap UI aid in discoverability of the editor's defaults as well as searching for commands or contexts all while not breaking out of the current flow state. Perhaps instead of a separate palette, these features could be extended to the command palette (cmd+shift+p) and by pressing tab, this Keymaps mode is entered showing the list of keybindings sorted as mentioned.