How to have different escapes for Ctrl+key and Ctrl+Shift+key

[andb0t]

• Your Windows build number: (Type ver at a Windows Command Prompt)

Microsoft Windows [Version 10.0.17134.648]

• What you're doing and what's happening: (Copy & paste specific commands and their output, or include screen shots)

I am using WSL with zsh and have a nice list of keybindings, using e.g. bindkey "^K" kill-line to bind pressing "Ctrl+k" to deleting all text from the cursor position to the EOL, like I have it in my atom text editor. I would now like to bind "Ctrl+Shift+k" to delete the entire line. Unfortunately, the WSL terminal has the same escape sequence for both, so it cannot detect the difference. I checked that using using sed -n l. How can I configure WSL to have different escape sequences?

Is it xterm below? If yes, can I just configure the underlying xterm to do what I want, e.g. in a .Xresources file?

• What's wrong / what should be happening instead:

I would have expected different escape sequences, such that I can bind different zsh widgets to them

[DHowett-MSFT]

I don't believe there is an encoding for standard control keys with shift held down. xterm and urxvt both emit ^K when I use Ctrl-Shift-K, and the documentation here indicates that extended encodings for Shift, Alt, Meta, Ctrl and combinations thereof only exist for "function keys".

[DHowett-MSFT]

I see: there is an xterm configuration option that allows you to specifically rebind what any particular key combination sends.

XTerm*vt100.translations: #override Ctrl ~Meta Shift <Key>a: string(0x1b) string("[65;5u")

This doesn't appear to be standard, unfortunately.

[andb0t]

Yes, that's what I would put in a .Xresources file. But WSL doesn't seem to read a ~/.Xresources file in my home. Any way to steer that?

[zadjii-msft]

That's correct - conhost.exe (the default terminal emulator on Windows for all commandline applications, including WSL) doesn't use anything like an .Xresources file.

I supposed having a file for overriding keybindings is something we could add support for in the future.

[andb0t]

Thanks! That would open so much configurability! Hope someone picks this up :)

[will]

I use the emacs bindings for powershell Set-PSReadlineOption -EditMode Emacs mostly to get ctrl-a to go to the start of the line and ctrl-e to go to the end. And that all is working great!

Except the third thing that is ingrained into my fingers and can never, ever be unlearned is ctrl-w to delete the last entire word. Which promptly closes the entire tab. 😱

Please have some way that will let me switch the tab-killing behavior of ctrl-w to windows-w.

[atwok]

I don't know if this is related or if this is a separate bug.

I'm using ubuntu.exe inside Windows Terminal. I'm ssh'd into a remote location. I'm using emacs in terminal mode.

Normally in emacs Alt+Shift+5 starts search and replace. According to emacs, it's receiving Ctrl-u 5.

Normally Alt is mapped to Ctrl+[, so if I do Ctrl+[, Shift 5, then search and replace works as expected.

If I just run ubuntu.exe, ssh in to the same remote host, start emacs in terminal mode, and use Alt+Shift+5, it passes through as expected.

[cpbotha]

To add more examples to this. I use Emacs 26.2 in WSL.

I can confirm the same behaviour as @atwok. To add to that, pressing ESC then shift-5 (M-% in Emacs parlance), Emacs registers ESC M-%. It looks like using ESC in Terminal (as of today) registers as ESC and meta / alt (M).

Furthermore, the standard emacs keys for going to start and end of buffer namly M-< and M-> can not be invoked in the terminal, neither with Alt+Shift+, or ESC - <.

All of the above (both escape- and alt-based procedures) works in a standard PowerShell 5 window (in which you can invoke wsl.exe) and of course using WSL directly.

[butchler]

To add another example, I have a key binding in Neovim for Shfit-Tab, but this does not work when using Windows Terminal+ssh.

This does work when using PuTTY, which maps Shift-Tab to ESC [ Z: https://github.com/github/putty/blob/49fb598b0e78d09d6a2a42679ee0649df482090e/unix/gtkwin.c#L1274

[zadjii-msft]

Hey so I just stumbled across this in the backlog. We'll probably not actually end up doing this with conhost ever - that UI is basically parked. This issue predates the Terminal announcement, so we were probably trying to be coy when tagging this up the first time. You probably could do something like this with the Windows Terminal though! You can always rebind key with the sendInput command:

{ "command": { "action": "sendInput", "input": "\u001b[D" }, "keys": "ctrl+shift+h" }
{ "command": { "action": "sendInput", "input": "\u001b[B" }, "keys": "ctrl+shift+j" }
{ "command": { "action": "sendInput", "input": "\u001b[A" }, "keys": "ctrl+shift+k" }
{ "command": { "action": "sendInput", "input": "\u001b[C" }, "keys": "ctrl+shift+l" }

(also vaguely related, #4999, but not really relevant to using that in WSL)

[neighthan]

A little more guidance on this in case it helps me or others in the future:

To set this up, open up the settings JSON file (when I checked, it didn't seem you could add sendInput actions through the GUI, but there's a long dropdown, so maybe I missed it). ctrl+shift+, will do this, by default. Then go to the "actions" entry (or create it if there is no top-level "actions" key) and add an entry as shown above:

"actions": [
  {
    "command": { "action": "sendInput", "input": "\u001b[210~" },
    "keys": "ctrl+shift+o"
  }
],

After saving, open a new WSL tab and test that you get the right escape sequence sent. E.g. if you used the example action above, then typing ctrl+v ctrl+shift+o should output ^[[210~ (ctrl+v makes it so the next key (or key combination) received is converted to a text format and shown; this is useful for debugging things with normally invisible control sequences). If things aren't set up properly, you should see the same output as if you did ctrl+v ctrl+o (^O).

Try pressing your key combination (e.g. ctrl+shift+o) without ctrl+v to see if this does anything in your terminal. This will help you avoid using an escape sequence that the terminal is already using. E.g. Windows terminal uses \e[200~ and \e[201~ for pasting, so don't override either of these.

Finally, you can set up your shell to do some custom behavior when it receives these special escape sequences. The exact method required will be shell-specific; for bash, you can put a line like this

bind -x '"\e[210~":"echo it worked!"'

in your ~/.bash_profile or ~/.bashrc. Then when you type ctrl+shift+o, you should see the message "it worked!" printed out. You can replace this with any command call or macro (remove -x for a macro).

[DHowett]

This is really great, @neighthan! Thanks!

I might recommend changing the example binding to not be \e[200~ just in case folks use it as the basis for a more complicated work. \e[200~ and \e[201~ are the guard sequences used by bracketed paste mode; I fear that rebinding them on the bash side will result in something strange happening when you copy/paste text!

Recording.2023-04-12.143437.mp4

[neighthan]

Hah, yeah, I didn't know what a good escape sequence to use would be. I got that one from chatgpt, but then I realized a few minutes ago that my pasting was messed up. I'm using \e[210~ now and haven't had issues yet. I'll update the example to use that for now to avoid causing issues for anybody else! Let me know if there's a better example code (or ideally range of codes?) to use that doesn't conflict with anything else.

I just checked, and this sequence seems to make the Windows terminal output 0~. That doesn't seem terrible to override. But having a list of safe to use sequences would be great.