How are keyboard inputs transmitted through Windows terminal and WSL2

Viewed 694

I'm using WSL (WSL2 in fact) for a few days and I'm a bit confuse about keyboard combination redirection and/or interception.

I have to say that my favorite tool to edit text is emacs, that use a lot of keyword combinations.

My stack is this one :

  • Under windows, I run Windows terminal (WT.exe)
  • In this terminal I open a tab which (afaik magically) is a shell on a linux subsystem. This subsystem is a Debian
  • In this shell I run emacs.

The whole thing looks like that :WT.exe calling WSL2 calling emacs

At this point, when I enter a key combination, it may be passed to emacs, or it may be intercepted/interpreted by any other layer of the stack.

For instance :

  • ctrl-e is interpreted by emacs : it move the caret to the end of file
  • ctrl-z is interpreted by wsl2 (afaik) : it pauses emacs as a background job
  • ctrl-tab is interpreted by windows terminal : it changes tab
  • alt-f4 is interpreted by windows : it closes windows terminal

And some of them are a mystery for me. For instance ctrl-_ (ctrl underscore), which is very useful on default emacs configuration, is not interpreted by emacs. It is translated at some point as "delete". In this configuration typing "delete" or "ctrl-_" is the very same thing : it removes the first character before the caret.

Very specifically and synthetically stated, my question would be : "How do I configure this stack to make emacs receive ctrl-_ ?"

Of course more generally, I really would like to know, how each layer works and is parameterized. For instance, is there a configuration file for WT and/or WSL2, that says which combination are forwarded, which one are interpreted and which one are ignored.

Additional Data :

  • If I run WSL2 through WT, but don't start emacs, ctrl-_ is also interpreted as "delete"
  • If I run another type of "tab" in WT, like cmd.exe or powershell, ctrl-_ is not interpreted as "delete". I don't know if it is interpreted at all
  • If I run WSL2 without WT, Ctrl-_ is not interpreted at all.
  • I didn't found any mention of ctrl-_ in WT config shortcuts.

Additional Data : I tried to run following python program in both stacks : WT/WSL and WT/CMD.EXE

import keyboard
while(True):
  c = keyboard.read_key()
  print(c)

On WT/CMD.EXE, the output is :

ctrl
_
_
ctrl

Which means it receive the keyboard info.

On WT/WSL2, it fails to run. Apparently "keyboard" is not compatible with WSL2. But this is not the question here.

1 Answers

A useful tool for debugging input on linux is showkey -a. You can use that to help debug what keys the client application is receiving. If you press a key and it doesn't display anything in the output, then there's a good chance it's being intercepted by the Terminal.

There's probably an open issue for this on the Terminal repo. #8458 looks similar.

is there a configuration file for WT and/or WSL2, that says which combination are forwarded, which one are interpreted and which one are ignored.

defaults.json is the file that contains all the keybindings that the Windows Terminal binds by default.

What WSL does is more complicated. IIRC, the inputrc file on linux is used readline (for bash, etc) to specify how certain keys are handled by the shell. But then there are also keys configured in stty that control other parts of the TTY interface. That part I understand less.

alt-f4 is interpreted by windows : it closes windows terminal

FWIW That's actually a application-level keybinding. The Terminal handles that key manually, so that people can optionally disable it. See defaults.json

Related