Sequence CTRL+\ is not detected in some keyboard layouts #11653

@zadjii-msft commented on GitHub (Dec 2, 2020):

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:

@zadjii-msft commented on GitHub (Dec 2, 2020): 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 <kbd>ctrl+\\</kbd>? It should look something like: ![image](https://user-images.githubusercontent.com/18356694/100876612-3b8b5a00-346d-11eb-8ef9-7e98cd4f3b98.png)

claunia commented

@ojroques commented on GitHub (Dec 2, 2020):

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.

@ojroques commented on GitHub (Dec 2, 2020): I'm using the [UK extended layout](http://kbdlayout.info/kbdukx/) 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.

claunia commented

@sashkachan commented on GitHub (Dec 8, 2020):

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.

@sashkachan commented on GitHub (Dec 8, 2020): 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.

claunia commented

@ojroques commented on GitHub (Dec 13, 2020):

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?

@ojroques commented on GitHub (Dec 13, 2020): 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?

claunia commented

@DHowett commented on GitHub (Dec 17, 2020):

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!

@DHowett commented on GitHub (Dec 17, 2020): 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](https://github.com/microsoft/terminal/issues/7067#issuecomment-664670923)? Type out a couple <kbd>Ctrl+\\</kbd> sequences and send a screenshot (so we can see which records are red and which are not) Thanks!

claunia commented

@ojroques commented on GitHub (Dec 17, 2020):

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 commented on GitHub (Dec 17, 2020): 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: ![image](https://user-images.githubusercontent.com/23409060/102464990-62d94e00-404d-11eb-84bb-8305bae5ddf3.png) 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: ![image](https://user-images.githubusercontent.com/23409060/102466080-c9ab3700-404e-11eb-9062-efc91f4cdf8c.png)

claunia commented

@ojroques commented on GitHub (Dec 17, 2020):

I've checked the source and it seems it's due to this particular line:
b8e6b8e27c/src/cascadia/TerminalCore/Terminal.cpp (L763) (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?

@ojroques commented on GitHub (Dec 17, 2020): I've checked the source and it seems it's due to this particular line: https://github.com/microsoft/terminal/blob/b8e6b8e27c2c902ce18798904ce09ff32d2f68fd/src/cascadia/TerminalCore/Terminal.cpp#L763 (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: ![image](https://user-images.githubusercontent.com/23409060/102502655-2f171c00-407f-11eb-9ed4-d3109b1f0bc8.png) 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: ![image](https://user-images.githubusercontent.com/23409060/102502853-671e5f00-407f-11eb-9679-381bdbcb903f.png) I'd expect that for the same vkey + scan code we would get the same Unicode character... what is happening there?

claunia commented

@zadjii-msft commented on GitHub (Jan 21, 2021):

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

@zadjii-msft commented on GitHub (Jan 21, 2021): You know, that's a good question. I don't know what's happening there. Maybe @lhecker might?

claunia commented

@lhecker commented on GitHub (Jan 22, 2021):

I'll look into it. 👍

@lhecker commented on GitHub (Jan 22, 2021): I'll look into it. 👍

claunia commented

@lhecker commented on GitHub (Jan 24, 2021):

@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.

@lhecker commented on GitHub (Jan 24, 2021): @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: ![wt-issue-8458](https://user-images.githubusercontent.com/2256941/105634204-350dd300-5e5d-11eb-8bcb-03cf50f38b5b.png) 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.

claunia commented

@DHowett commented on GitHub (Jan 28, 2021):

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

@DHowett commented on GitHub (Jan 28, 2021): Triaged into 1.7 since we've got our best people looking at it. :smile:

claunia commented

@ghost commented on GitHub (Mar 1, 2021):

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

Handy links:

@ghost commented on GitHub (Mar 1, 2021): :tada: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](https://github.com/microsoft/terminal/releases/tag/v1.7.572.0) * [Store Download](https://www.microsoft.com/store/apps/9n8g5rfz9xk3?cid=storebadge&ocid=badge)

claunia commented

@XL64 commented on GitHub (Feb 29, 2024):

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 : https://github.com/microsoft/WSL/issues/11041

@XL64 commented on GitHub (Feb 29, 2024): 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 : https://github.com/microsoft/WSL/issues/11041

claunia commented

@j4james commented on GitHub (Mar 1, 2024):

@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.

@j4james commented on GitHub (Mar 1, 2024): @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 <kbd>Ctrl</kbd>+<kbd>_</kbd> 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.

claunia commented