Sequence CTRL+\ is not detected in some keyboard layouts

[ojroques]

Environment

Windows build number: 10.0.19041.0
Windows Terminal version (if applicable): Windows Terminal Preview v1.5.3242.0

Edit: I've updated the description.

Here is the old one.

Steps to reproduce

1. Try to use a mapping containing CTRL+\ in an application: for instance CTRL+\ CTRL+n in Neovim to quit the built-in terminal or by adding a new mapping in tmux.

Actual behavior

Nothing happens. It seems the CTRL+\ sequence is completely ignored by Windows Terminal. I'm using WSL1 with Ubuntu 20.04 but I've tried in Powershell and same issue. I've also tried with another terminal emulator (kitty) and CTRL+\ works fine there.

I found maybe related issues: #1288, #521 but they are marked resolved and I'm still getting the bug. Any idea why?

Steps to reproduce

1. Change your keyboard layout to the UK extended layout
2. Launch the Terminal and run showkey -a (I'm using Ubuntu 20.04 in WSL)
3. Press CTRL-\

Actual behavior

Nothing happens. The CTRl-\ sequence goes undetected by the terminal. I've tried different layouts (US and French) and it works fine, so this issue seems tied to the choice of the keyboard layout.

Expected behavior

CTRL-\ is correctly detected. Maybe related issues: #1288, #521.

[zadjii-msft]

What keyboard layout do you use? Is it one that has an AltGr key?

Can you share the output of running showkey -a, then pressing ctrl+\? It should look something like:

[ojroques]

I'm using the UK extended layout so yes it has an AltGr key. I tried showkey -a but Ctrl-\ outputs nothing. Other Ctrl sequences works fine though.
Edit: I've tried with different layouts (US and UK) and it works. So it seems it is related to the UK extended layout in particular.

[sashkachan]

I am having the same problem with third party Colemak layout. Can't figure out why it's not passing through. In my case, I am trying Ctrl+_ (undo in Emacs). showkey also shows no input.

[ojroques]

I'm aware that this isn't a high priority issue since very few users should be affected. But it's quite annoying to me because it prevents me to use some features of my editor of choice (the built-in terminal of Neovim).

I would like to take a look at the code and maybe try to find the issue myself. @zadjii-msft could you tell me where I should start looking?

[DHowett]

The best place to start looking will be in Terminal.cpp's SendKeyEvent and SendCharEvent.

If you'd like to give us a quick debug trace, would you mind following the "input log" trace steps in this issue comment? Type out a couple Ctrl+\ sequences and send a screenshot (so we can see which records are red and which are not)

Thanks!

[ojroques]

Thanks for the info I'll look into the files your mentioned.

Here's the trace of me doing CTRL+\ using the UK extended keyboard layout:

There seems to be no trace of the release of \. When I change my keyboard layout to US, where the sequence works fine, I get this:

[ojroques]

I've checked the source and it seems it's due to this particular line:

terminal/src/cascadia/TerminalCore/Terminal.cpp

Line 763 in b8e6b8e

const auto result = ToUnicodeEx(vkey, scanCode, keyState.data(), buffer.data(), gsl::narrow_cast<int>(buffer.size()), 0b101, nullptr);

(related doc: https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-tounicodeex).

That function returns 0 meaning that the given vkey (here 220) has no associated Unicode character. And this is what we see in the screenshot when we use UK extended layout:

However what I don't understand is that when I switch to the standard UK layout, I see the same vkey but a different value for the unicode character:

I'd expect that for the same vkey + scan code we would get the same Unicode character... what is happening there?

[zadjii-msft]

You know, that's a good question. I don't know what's happening there. Maybe @lhecker might?

[lhecker]

I'll look into it. 👍

[lhecker]

@ojroques We use ToUnicodeEx to determine whether a given key event will likely produce a character (like "a") as opposed to a control character or similar (like pressing an arrow key). This is important as the operating system knows more about the current state of the keyboard than our application and will help us to support dead keys (´+e = é for instance).

@zadjii-msft This issue occurs, because some non-US keyboard layouts apparently do not contain Ctrl-key mappings at all:

In fact it turns out that the affected keyboards layouts don't contain any mappings for Ctrl-key combinations. It appears as if Windows simply defaults a combination of Ctrl and any A-Z key to ^A-^Z, if the current keyboard layout has no mappings itself.
AFAICS the solution is to Ctrl+key combinations in TerminalInput::HandleKey even if GetCharData is zero. PR incoming.

[DHowett]

Triaged into 1.7 since we've got our best people looking at it. 😄

[ghost]

🎉This issue was addressed in #8870, which has now been successfully released as Windows Terminal Preview v1.7.572.0.:tada:

Handy links:

• Release Notes
• Store Download

[XL64]

I have similar issue with french layout and ctrl+_ not correctly passed to the linux applications but as it can be reproduced within any other windows terminals I tried, i guess it's more a wsl issue. I opened an issue on WSL github repo : microsoft/WSL#11041

[j4james]

@XL64 That sounds like #11194, which should have been fixed in the v1.20 preview release. I've just done a test with a French keyboard layout in WSL, and Ctrl+_ is definitely working as expected for me. If you can still reproduce the issue on version 1.20, it's best you open another issue and provide more details.

[XL64]

Indeed, it is fixed. what is strange is that other native windows terminal are affected too.