Support remapping keybindings

[kumarpiyush]

Bash uses Ctrl-W as delete word, and bash applications overload the use of Ctrl-W (e.g. in vim, Ctrl-W + W is used to cycle through window splits). Using Ctrl-W for close tab breaks those functionalities.

[zadjii-msft]

Soon^tm we'll support re-mapping keybindings, so this won't be an issue :)

[codingo]

@zadjii-msft I'm still building this so apologies if it already exists, but could you ensure there's a way to export/import settings like these as well? I carry around a dot files repository as I'm sure many others do and I'd love to be able to setup terminator bindings for this in new VM's quickly/easily.

[carlos-zamora]

For now, if you want to mess with some of the keybindings, check out the "TerminalApp" project and go to the CascadiaSettings::_CreateDefaultKeybindings() in CascadiaSettings.cpp

[bef178]

Could the shortcut default to ctrl-d to keep the same user experience as Linux terminal?

[ffes]

It doesn't fix the issue entirely obviously, but Ctrl+F4 is a more Windows-like key to close a tab. Seems a decent alternative until re-mapping fo keybindings is done. Not used too much in command line tools AFAIK.

Could the shortcut default to ctrl-d to keep the same user experience as Linux terminal?

Ctrl+D is a key in vim as well. It works similar to PgDn so I imagine used a lot as well. Almost all Ctrl+letter keys will cause issues in vim.

[bef178]

Ctrl+D is a key in vim as well. It works similar to PgDn so I imagine used a lot as well. Almost all Ctrl+letter keys will cause issues in vim.

Did not experience such trouble in Linux terminal with vim. ctrl-d is sent to current "app" in terminal, rather than a "hook" or intercepted by the terminal itself. Looks like it is cmd and powershell should be changed.

Then agree ctrl-f4 is reasonable for Terminal to intercept.

[zadjii-msft]

The ability to set your own custom keybindings in the profiles.json file doesn't exist quite yet, but we're planning on adding support soon^tm

[zadjii-msft]

This is now the official thread for "Support remapping keybindings"

[DHowett-MSFT]

and "reevaluate the defaults".

[zadjii-msft]

I'm going to add some context here from what I had in our internal work tracker:

Keybindings should be serialized in the following format:

[
        { "keys": ["f2"], "command": "next_bookmark" },
	{ "keys": ["shift+f2"], "command": "prev_bookmark" },
	{ "keys": ["ctrl+f2"], "command": "toggle_bookmark" },
	{ "keys": ["ctrl+shift+f2"], "command": "clear_bookmarks" },
]

Where each keybinding has a plaintext string that encodes the keychord, and the name of the command that it is mapped to.

[
        { "keys": ["ctrl+t"], "command": "newTab" },
	{ "keys": ["ctrl+tab"], "command": "nextTab" },
	{ "keys": ["ctrl+shift+tab"], "command": "prevTab" },
]

As an example

VKeys that map to letters should be lowercase in the settings we save, but we shouldn't care if they're upper or lower when we read the file.
For something like '@', which doesn't have it's own vkey, we shouldn't allow that as a char in the keybindings. shift+2 would be the US keyboard way of encoding that keybinding.
Arrows, pgup/dn, home/end/etc, tab, backspace, F1-12, esc, +/- all need strings their vkeys should be mapped too.

Additionally, all of the "actions" will need simple strings describing the action that we can use as the value for "command".

I'd store the keychord as an array with a single value for the time being. should we later want to implement keybindings with multiple "notes" in the chord, (e.g ["ctrl+k", "ctrl+c"] would be the default for VS to comment a line) then we'll be happy the keybindings are already an array.

[robinwilson16]

Please can certain key combos be left unmapped by default so the new terminal functions the same as CMD and WSL do so that commands such as Ctrl+W are passed as input to the interpreter rather than picked up by the application then I will be able to search in nano again without switching.

[zadjii-msft]

So to be fair, conhost.exe doesn't have all that many keybindings by default (Ctrl+(shift+)C/V for copy/paste, Ctrl+M for mark mode, that's all I can even think of), while Windows Terminal is going to need a decent number of keybindings. There are just more things that the terminal does.

If we switch the binding for close window to Ctrl+Shift+W, then we'll undoubtably get still get issues saying "Ctrl+Shift+W for close window by default impedes my workflow, please change it to <blah>". There's no best set of keybindings, except for allowing quick changing with the settings.

[robinwilson16]

Maybe it would be better to not map anything by default then at least there can be no conflicts. Or the first time it is pressed a popup could appear asking whether you would like the command passed to the remote machine or interpreted locally with a checkbox to remember the selection.

[xafizoff]

Hello. I'm using MidnightCommander/MCEdit inside WSL and have no problems. But if I run WSL inside the Terminal, some annoying things happen:

1. MC's textual GUI does not respond to mouse clicks
2. Hotkeys does not work, except functional keys (F1-F12)

Command line for WSL: wsl ~ -d Ubuntu-18.04

[zadjii-msft]

@xafizoff could you file a new issue for the second problem you mentioned, so we can triage and investigate it? This thread is specifically concerning adding support for remappable keybindings.

The first issue you mentioned, mouse clicks not working in MC, is due to #376