Allow multiple keybindings to work

[OldStarchy]

This is not a duplicate of

• Feature Request: Keybinding Overloading #39888
  I'm specifically asking to run multiple commands in sequence.
• Macro like keybindings #871
  Unconditionally running multiple commands per keypress is already possible using the geddski.macros extension. Also, implementing this would not necessarily satisfy #871 since its up to the bound command to decide if execution should continue to other bindings.

Problem

Both yzhang.markdown-all-in-one and takumii.markdowntable define keybindings to overwrite the tab key. In both cases, the behavior is dependant on the content and the cursor position.

The yzhang.markdown-all-in-one binding allows for indenting list items. If the cursor is not in a list, a tab character is inserted instead.

The takumii.markdowntable binding moves the cursor between cells in a formatted table. If the cursor is not in a table, a tab character is inserted instead.

Both of these provide a "new" behavior in some cases and falls back to a "default" if the new behaviour is not applicable. The use cases for these two new behaviors are unrelated, but due to the way keybindings work in vscode, they are fully incompatible.

See these issues for more context

• Restrict key binding context to reduce Tab key conflict yzhang-gh/vscode-markdown#1015
• [compatibility] doesn't work well with "Markdown All in One" extension takumisoft68/vscode-markdown-table#18

New Feature

Keybindings should be able to call a preventDefault function (or for compatibility purposes, an allowDefault or callNext function such that if the current keybinding determines it is ineffective control may be handed back to either the next matched keybinding if one (or more) exists or the default behavior.

Additionally, some way to order the execution of the bindings would likely be beneficial. This would not require a new GUI either, adding a new property to a keybinding definition "priority": 1 which can be used to define the execution order. (Though in this case, the order the keybindings are executed would not matter)

[
	{
		"key": "tab",
		"command": "markdowntable.nextCell",
		"when": "editorTextFocus && !editorReadonly && !editorTabMovesFocus && !inSnippetMode && !suggestWidgetMultipleSuggestions && !suggestWidgetVisible && editorLangId == 'markdown'",
		"priority": 1
	},
	{
		"key": "tab",
		"command": "markdown.extension.onTabKey",
		"when": "editorTextFocus && !editorReadonly && !editorTabMovesFocus && !inSnippetMode && !suggestWidgetMultipleSuggestions && !suggestWidgetVisible && editorLangId == 'markdown'",
		"priority": 2
	}
]

In this case, the higher priority command markdown.extension.onTabKey will execute first, falling back to markdowntable.nextCell, then finally the default action provided by VSCode to insert a tab character (or indentation with spaces).

[alexdima]

I understand the kind of system you are proposing, but we don't want to build that. This is the reason we have created context keys and dispatch keybindings based on when conditions. The philosophy of our current keybinding subsystem is that keys need to be dispatched synchronously to the direct command that needs to execute. The main reason we have opted for such a design is that this allows immediately dispatching of keybindings to the relevant command. You can imagine how a system where one can delegate to the next command using a callNext function could end up with a situation where keybindings are dispatched out-of-order. (e.g. user presses ctrl+c, ctrl+v), yet because of a slow handler for ctrl+c that uses just a bit of await, the ctrl+v gets dispatched before ctrl+c. The way to solve that would be to build async queues to ensure in-order dispatching, but that is also problematic because there is nothing worse than an editor that takes arbitrary amount of time to react to keybindings. Imagine a slow handler for ctrl+c (takes 5s) that would block all other subsequent keypresses; that would result in a really bad end-user experience.

The solution here is for the yzhang.markdown-all-in-one extension to create a new context key e.g. named selectionInMarkdownList and for the takumii.markdowntable extension to create a new context key e.g. named selectionInMarkdownTableCell. These keys need to be proactively maintained (set to true or false) based on the current active text editor and the current cursor position (things which are available via API). Once custom context keys are maintained, the when conditions for the keybindings need to be updated to make use of them.

Custom context keys can be created/updated using commands.executeCommand('setContext', 'contextKey', true);. We have an issue #10471 to create better API in this area.

[OldStarchy]

Thanks for the clear explanation.