Feature Request: Keybinding Overloading
brandondrew opened this issue · comments
I'm not asking for the ability to run multiple commands in sequence, as mentioned in
or as addressed with the macros extension
I'd like to be able to assign a given keybinding to multiple different commands separately, and if multiple commands are applicable in the current context when the keystroke is used, present the user with a menu of the options, rather than considering it a conflict, where only one can "win".
There are many significant benefits to this:
- You don't have to worry about keybindings from your multiple extensions conflicting with each other.
- All extension authors can add the keybinding they think makes the most sense, instead of telling you to manually add it in your own personal keybindings.json.
- You don't have to worry about your personal keybindings clobbering a default keybinding (this sort of conflict does not appear when you use "Show Conflicts"—at least it did not in my tests).
- You will never accidentally use the wrong command because of a conflict in which you expected another command to be triggered by your keybinding.
- You can purposefully add multiple related commands to the same keybinding, so that you have fewer bindings to memorize. For example,
- you could assign all of your Git-related commands to ⌘⌥G, or, for more focused groupings,
- you could assign all variations of Git commands related to adding files to ⌘⌥A, and those related to commiting to ⌘⌥C, and so forth.
- You can experiment with changed keybindings without having to change the whole world in order to accommodate the change you think you might prefer.
Since there may be people who have grown accustomed to existing conflicts in their keybindings (and accustomed to the current winner) it would make sense for this behavior to have a setting to turn it on or off, so that they are not presented with a menu containing what used to be considered "conflicts" but under the new behavior are simply alternate options assigned to the same keystroke.
I've just discovered that VS Code apparently lacks a Key Resolver, which makes this suggestion even more valuable than I realized when I posted this. (But even with a key resolver, this would be very valuable, for the reasons given above.)
I also encountered a conflict that resulted from the "one binding wins" approach, which caused me much initial confusion.
While editing a markdown file, I tried navigating one tab to the left, but nothing happened. After testing the usual suspects—frozen OS, keyboard disconnected, accidentally activated MouseKeys—I had to test whether VS Code supported that nearly universal keystroke.
Of course it does, but it turns out some Markdown-related extension clobbered it, so that ⌘⇧[ was instead bound to changing the heading level of the current line. Since it had no heading level there was no change visible, hence the appearance that the keystroke had done nothing.
Eliminating this sort of confusion would be just one of the many benefits of replacing a one-binding-wins approach with a menu-of-bound-commands approach.
It should be number 1 implemented feature.
@alexandrudima any chance of this being pulled out of the backlog?
This is certainly something I would like to see implemented as it causes an extension that I built to break the functionality of another