Repository: vscode
Issue: Feature: Settable "keyboard.chords.mode"
Labels: feature-request,keybindings

<h1 align=center><img alt="consequential inaccessibility ≠ incidental feature request" src="https://upload.wikimedia.org/wikipedia/commons/3/3b/Antu-preferences-desktop-accessibility-32.svg" height=48 /></h1>

<details><summary align=center><b><code>Explainer</code></b></summary>

---

**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

</details>

---

**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.

<details><summary>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…</summary><p>

> 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"<kbd>cmd</kbd>+<kbd>k</kbd> <kbd>cmd</kbd>+<kbd>w</kbd>"  would not trigger if the <kbd>cmd</kbd> key was released midway, or if <kbd>cmd</kbd> 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.

</details>

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 <kbd>cmd</kbd>+<kbd>k</kbd> 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:

```json
// 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 <kbd>cmd</kbd>+<kbd>k</kbd> 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.