Vscode: Feature: Settable "keyboard.chords.mode"

[SMotaal]

Explainer

---

Note — The following was added after reopening the issue… please read to understand my perspective when I opened this issue a while back.

TL;DR;

This issue for folks like myself comes with accessibility related burdens that extend far beyond feeling 😯 because you triggered the wrong thing… For every unexpected outcome, there is a long period of observing to look for what makes it happen, then you need to figure out where to look for possible causes, then you find that, then you look for ways to fix it, creating all sorts of noise and all sorts of visual and cognitive burdens.

So you get the gist, I am disabled my way, it never got in my way, but your chords feature is an actual disability not of my way, it is in my way!

And so yes all that just because of a shortcut, yes, that is what others don't get to see — which is a good thing, but not accepting that some suffer this is hardly a fair thing to do just because there is more who don't need bother… please ❤️

DR;

consequential inaccessibility ≠ incidental feature request

---

Proposal

I'd like to propose a solution that will allow everyone to decide the degree of complexity they are comfortable with, without the need for any complicated configuration and possible very little change to the existing system. The user simply decides which "keyboard.chords.mode" they want to use in the settings.json, which will augment how VS code behaves immediately after the first key of a possible chord is pressed.

This was in the original issue, it is not meant as a "feature request" merely my naïve way to try to "offer solutions" not "problems" but I realize now my mistake…

Let's say the current unchanged behaviour is the "default" mode, we can also consider an alternative "off" mode, and maybe my favourite one "continuous" is the third mode, may be even extension-defined or something more complicated down the road. When "off", VS code does not even need to initialize any chord effects. When "default", VS code does what it normally does.

For "continuous" a new mode all together is introduces to replace the current sparse key sequences with modifier(s) + key(s) combinations. This would instead require the first key to include one or more modifiers with one or more letter, except the modifiers should remain pressed before the following keys in the sequence. So for instance"cmd+k cmd+w" would not trigger if the cmd key was released midway, or if cmd is not yet released (allowing sequences that go beyond two keys), then as soon as the modifier is released, all keybindings exactly matching "key": "cmd+k cmd+w" would be the intended keys, excluding any other partial matches like "key": "cmd+k" or "key": "cmd+k cmd+w cmd+1"... etc.

But, please come your own solution, I do not want chords, not the way they are at least, so on/off is better to me than trouble/off/useful — which was misrepresented above, sorry!

---

Why

From time to time commonly used keyboard shortcuts, specifically those that overlap with the first key in the chord of others, stop working. The reasons are always different, but ultimately, the underlaying cause or the side effect will be fixed by finding the offending keybinding which is guaranteed to either be a default or extension default, and then adding two or more new bindings to try to gracefully avoid the conflict.

In reality, the current chord implementation is extremely evolved to do amazing work coalescing predefined keybindings from many sources, but as far as the user is concerned, keybindings.json is an extremely complicated file to troubleshoot. If a conflict did not involve chords, it is not complicated, and most of the time using the Keyboards Shortcut editor is all you need to substitute any offenders, which result in 1 or 2 records in the json file at the most.

Issue

So let me close with my incomplete issue (which likely you would not like filed).

Currently my cmd+k no longer clears the terminal and my keybindings to fix that are not close to how things were before either a new VS code change or some extension I recently added (or something else).

• VSCode Version: Version 1.22.2 (1.22.2)
• OS Version: macOS 10.13.4 (17E199)

Steps to Reproduce:

1. Don't know

Current Crude Fix:

// keybindings.json

    {
        "key": "cmd+k",
        "command": "workbench.debug.panel.action.clearReplAction",
        "when": "!editorFocus && inDebugMode" // but only if panel is open and showing please
    },
    {
        "key": "cmd+k",
        "command": "workbench.action.terminal.clear",
        "when": "terminalFocus" // did xterm break this (I don't know)
    },
    {
        "key": "cmd+k",
        "command": "workbench.action.terminal.clear",
        "when": "!editorFocus && !inDebugMode" // but only if in terminal please
    }

Does this issue occur when all extensions are disabled?: Yes but which one

I don't think it is possible for users of different skillsets to figure out the trickle down logic the VS code uses to determine when to expect a next chord key when they are 100% sure they bound cmd+k to clear the terminal when the focus is in the terminal. Even then, how many negative bindings would it take to ensure that the positive binding always triggers.

Thanks and really excited to see the next iteration of this revolutionary keyboard handling system.

[vscodebot[bot]]

This issue is being closed to keep the number of issues in our inbox on a manageable level, we are closing issues that are not going to be addressed in the foreseeable future: We look at the number of votes the issue has received and the number of duplicate issues filed. More details here. If you disagree and feel that this issue is crucial: We are happy to listen and to reconsider.

If you wonder what we are up to, please see our roadmap and issue reporting guidelines.

Thanks for your understanding and happy coding!

[SMotaal]

I'd like to open this again please… I guess it is a good thing not many people have accessibility related differences… but if everytime you expect people to get over all those "please talk to the robot" layers of normality is king, you will never see it.

Please realize, when you alter keyboard behaviour, you cannot expect people to come to your court to defend their position. You need to offer "no special mode" please.

/cc @alexdima @ramya-rao-a

[SMotaal]

Thanks @alexdima, I truly appreciate reopening this so quickly, thank you!

I hesitate to state the obvious, but @vscodebot not working is a little more predictable, would greatly appreciate some context when you get a chance please :)

[SMotaal]

@alexdima it is very very sad to think that an issue open for close to two years does not warrant a single human gesture.

When I see this:

Your effort on is appreciated, everyone's hard work on vscode is appreciated, but to be honest, I don't think any more work is needed to show how low priority people get to feel when everyone thinks it is irrelevant to clarify and make sure if "unknown user who may have no clue" has some clue.

This is merely meant to be expressed to the vscode team and the community, once again I personally thank you for your effort!