AltGR SEQUENCES DO NOT WORK -- Can&#39;t type any AltGr combinations in Windows Terminal #766

@patriksvensson commented on GitHub (May 7, 2019):

Update: Same thing happens with all digits when combined with Alt Gr.

@patriksvensson commented on GitHub (May 7, 2019): Update: Same thing happens with all digits when combined with `Alt Gr`.

claunia commented

@zadjii-msft commented on GitHub (May 7, 2019):

You know, this is probably on me. We're probably not getting vkey correctly for AltGR combos somewhere in TermControl.cpp, when we get the KeyDown event.

@zadjii-msft commented on GitHub (May 7, 2019): You know, this is probably on me. We're probably not getting vkey correctly for AltGR combos somewhere in TermControl.cpp, when we get the KeyDown event.

claunia commented

@watermelonpizza commented on GitHub (May 8, 2019):

Kinda unrelated, but what software did you use to get a recording with the keys you pressed in the gif @patriksvensson ?

@watermelonpizza commented on GitHub (May 8, 2019): Kinda unrelated, but what software did you use to get a recording with the keys you pressed in the gif @patriksvensson ?

claunia commented

@patriksvensson commented on GitHub (May 8, 2019):

@watermelonpizza I used Carnac to display the key presses and ScreenToGif to capture the window.

@patriksvensson commented on GitHub (May 8, 2019): @watermelonpizza I used [Carnac](http://code52.org/carnac/) to display the key presses and [ScreenToGif](https://www.screentogif.com) to capture the window.

claunia commented

@watermelonpizza commented on GitHub (May 9, 2019):

Oh carnac, awesome thanks! I'll add that to my list of goodies :)

@watermelonpizza commented on GitHub (May 9, 2019): Oh carnac, awesome thanks! I'll add that to my list of goodies :)

claunia commented

@DHowett-MSFT commented on GitHub (May 9, 2019):

I think this is a duplicate of #487.

@DHowett-MSFT commented on GitHub (May 9, 2019): I think this is a duplicate of #487.

claunia commented

@DHowett-MSFT commented on GitHub (May 9, 2019):

Whoops, it looks like the left hand doesn't know what the right hand is doing, and I just created a circular duplicate link.

@DHowett-MSFT commented on GitHub (May 9, 2019): Whoops, it looks like the left hand doesn't know what the right hand is doing, and I just created a circular duplicate link.

claunia commented

@jozsefsallai commented on GitHub (May 9, 2019):

Can confirm this issue on Windows version 10.0.18362.30 with Hungarian keyboard layout. The behavior is different, depending on what console I'm using:

cmd: it just writes the character but in uppercase
powershell: does nothing at all
git bash: doesn't write out anything, but plays the default beep

@jozsefsallai commented on GitHub (May 9, 2019): Can confirm this issue on Windows version 10.0.18362.30 with Hungarian keyboard layout. The behavior is different, depending on what console I'm using: - cmd: it just writes the character but in uppercase - powershell: does nothing at all - git bash: doesn't write out anything, but plays the default beep

claunia commented

@lhecker commented on GitHub (May 10, 2019):

@zadjii-msft I found your (?) AltGr related comment in terminalInput.cpp.
On my German keyboard the control key state is LEFT_CTRL_PRESSED | LEFT_ALT_PRESSED instead of the seemingly expected LEFT_CTRL_PRESSED | RIGHT_ALT_PRESSED though.
Furthermore the pressed virtual key is e.g. "Q" instead of some already transform unicode character.

Thus I replaced...
660d31ac52/src/terminal/input/terminalInput.cpp (L415-L419)
with...

if (keyEvent.IsAltPressed() && keyEvent.IsCtrlPressed())
{
    return false;
}

...and it works! For now. 😅 It will delegate the handling to WM_CHAR/_CharacterHandler which according to Google is more robust for AltGr handling. (?) (I'm not very familar with Windows programming yet.)
What do you think of this? Should I submit a PR?

@lhecker commented on GitHub (May 10, 2019): @zadjii-msft I found your (?) AltGr related comment in [`terminalInput.cpp`](https://github.com/microsoft/Terminal/blob/660d31ac522186e615ec243de2a434c273464828/src/terminal/input/terminalInput.cpp#L400-L419). On my German keyboard the control key state is `LEFT_CTRL_PRESSED | LEFT_ALT_PRESSED` instead of the seemingly expected `LEFT_CTRL_PRESSED | RIGHT_ALT_PRESSED` though. Furthermore the pressed virtual key is e.g. "Q" instead of some already transform unicode character. Thus I replaced... https://github.com/microsoft/Terminal/blob/660d31ac522186e615ec243de2a434c273464828/src/terminal/input/terminalInput.cpp#L415-L419 with... ```cpp if (keyEvent.IsAltPressed() && keyEvent.IsCtrlPressed()) { return false; } ``` ...and it works! For now. 😅 It will delegate the handling to WM_CHAR/_CharacterHandler which according to Google is more robust for AltGr handling. (?) (I'm not very familar with Windows programming yet.) What do you think of this? Should I submit a PR?

claunia commented

@krokofant commented on GitHub (May 10, 2019):

@lhecker Awesome! Now this is actually usable 🎉

@krokofant commented on GitHub (May 10, 2019): @lhecker Awesome! Now this is actually usable 🎉

claunia commented

@ghosty141 commented on GitHub (May 11, 2019):

@lhecker Yes, please submit a PR. On german keyboards I can't input the pipe right now which makes the terminal kinda hard to use.

@ghosty141 commented on GitHub (May 11, 2019): @lhecker Yes, please submit a PR. On german keyboards I can't input the pipe right now which makes the terminal kinda hard to use.

claunia commented

@lhecker commented on GitHub (May 11, 2019):

I feel like my change is incorrect though. There must be a reason why not all characters are handled by WM_CHAR right?
Due to that I'd like to wait for @zadjii-msft or @DHowett-MSFT's feedback first. I think? 😅

@lhecker commented on GitHub (May 11, 2019): I feel like my change is incorrect though. There must be a reason why not all characters are handled by `WM_CHAR` right? Due to that I'd like to wait for @zadjii-msft or @DHowett-MSFT's feedback first. I think? 😅

claunia commented

2026-01-30 22:02:59 +00:00

@sagood commented on GitHub (May 12, 2019):

The actual cause is in Terminal.cpp

DWORD modifiers = 0
                      | (ctrlPressed? LEFT_CTRL_PRESSED : 0)
                      | (altPressed? LEFT_ALT_PRESSED : 0)
                      | (shiftPressed? SHIFT_PRESSED : 0);

You can see that the RIGHT_ALT_PRESSED is never correctly detected here, which causes keyEvent.IsAltGrPressed in TerminalInput::HandleKey return false.

Btw, the modifiers state is acquired by _GetPressedModifierKeys() in TermControl::_KeyDownHandler(). instead of a boolean value, you can pass the modifiers state directly into SendKeyEvent, and determine whether the left/right ctrl, left/right alt, left/right shift is pressed later.

And there are already defined as follows in VirtualKey, which can be used in TermControl::_GetPressedModifierKeys()

        LeftShift = 160,
        RightShift = 161,
        LeftControl = 162,
        RightControl = 163,
        LeftMenu = 164,
        RightMenu = 165,

@sagood commented on GitHub (May 12, 2019): The actual cause is in Terminal.cpp ```cpp DWORD modifiers = 0 | (ctrlPressed? LEFT_CTRL_PRESSED : 0) | (altPressed? LEFT_ALT_PRESSED : 0) | (shiftPressed? SHIFT_PRESSED : 0); ``` You can see that the RIGHT_ALT_PRESSED is never correctly detected here, which causes keyEvent.IsAltGrPressed in TerminalInput::HandleKey return false. Btw, the modifiers state is acquired by _GetPressedModifierKeys() in TermControl::_KeyDownHandler(). instead of a boolean value, you can pass the modifiers state directly into SendKeyEvent, and determine whether the left/right ctrl, left/right alt, left/right shift is pressed later. And there are already defined as follows in VirtualKey, which can be used in TermControl::_GetPressedModifierKeys() ```cpp LeftShift = 160, RightShift = 161, LeftControl = 162, RightControl = 163, LeftMenu = 164, RightMenu = 165, ```

claunia commented

@lhecker commented on GitHub (May 12, 2019):

Ah nice catch @sagood!
Unfortunately fixing this issue will not be enough as far as I can see...
TerminalInput::HandleKey apparently assumes that when AltGr is pressed, the OS has already "pretranslated the UnicodeChar to the proper alternative value", which is not the case for e.g. AltGr+Q (= @) on a German keyboard.
Meaning the current logic around IsAltGrPressed() is already kinda flawed.

@lhecker commented on GitHub (May 12, 2019): Ah nice catch @sagood! Unfortunately fixing this issue will not be enough as far as I can see... `TerminalInput::HandleKey` apparently assumes that when AltGr is pressed, the OS has already "pretranslated the UnicodeChar to the proper alternative value", which is not the case for e.g. AltGr+Q (= @) on a German keyboard. Meaning the current logic around `IsAltGrPressed()` is already kinda flawed.

claunia commented

2026-01-30 22:02:59 +00:00

@sagood commented on GitHub (May 12, 2019):

@lhecker I have tried to use RIGHT_ALT_PRESSED instead to initialize DWORD modifiers. I tested AltGr + '+' (= ~), it will be correctly shown in the console.
AltGr + < (= |) also works.

But AltGr+Q does not seem work indeed. weird.
AltGr + E (= €) does not work either.

By setting up a new c# UWP, I observed that the key sequence while using AltGr is as follows,

Menu
Control
Q

(take AltGr + Q as an example)

@sagood commented on GitHub (May 12, 2019): @lhecker I have tried to use RIGHT_ALT_PRESSED instead to initialize DWORD modifiers. I tested AltGr + '+' (= ~), it will be correctly shown in the console. AltGr + < (= |) also works. But AltGr+Q does not seem work indeed. weird. AltGr + E (= €) does not work either. By setting up a new c# UWP, I observed that the key sequence while using AltGr is as follows, ``` Menu Control Q ``` (take AltGr + Q as an example)

claunia commented

2026-01-30 22:02:59 +00:00

@sagood commented on GitHub (May 12, 2019):

Further debugging shows that if you force the program to run the first condition branch of TerminalInput::HandleKey from terminalInput.cpp as shown below,

if (!fKeyHandled)
            {               
                if ((keyEvent.GetVirtualKeyCode() < '0' || keyEvent.GetVirtualKeyCode() > 'Z') &&
                    keyEvent.GetVirtualKeyCode() != VK_CANCEL)
                {
                     // !!!force the AltGr+'Q/E' case to run here, not the one below
                    fKeyHandled = _TranslateDefaultMapping(keyEvent, GetKeyMapping(keyEvent), GetKeyMappingLength(keyEvent));  
                }
                else
                {
                    ...
                }
            }

AltGr+Q will work.

@sagood commented on GitHub (May 12, 2019): Further debugging shows that if you force the program to run the first condition branch of TerminalInput::HandleKey from terminalInput.cpp as shown below, ```cpp if (!fKeyHandled) { if ((keyEvent.GetVirtualKeyCode() < '0' || keyEvent.GetVirtualKeyCode() > 'Z') && keyEvent.GetVirtualKeyCode() != VK_CANCEL) { // !!!force the AltGr+'Q/E' case to run here, not the one below fKeyHandled = _TranslateDefaultMapping(keyEvent, GetKeyMapping(keyEvent), GetKeyMappingLength(keyEvent)); } else { ... } } ``` AltGr+Q will work.

claunia commented

2026-01-30 22:03:00 +00:00

@sinni800 commented on GitHub (May 17, 2019):

How about AltGr+ß for \ on the German keyboard, that one has the same problem

@sinni800 commented on GitHub (May 17, 2019): How about AltGr+ß for \ on the German keyboard, that one has the same problem

claunia commented

2026-01-30 22:03:00 +00:00

@mKay00 commented on GitHub (May 17, 2019):

All AltGr keyboard combinations are affected by the same issue.

@mKay00 commented on GitHub (May 17, 2019): All AltGr keyboard combinations are affected by the same issue.

claunia commented

2026-01-30 22:03:01 +00:00

@MattKuhr commented on GitHub (May 18, 2019):

Any progress on this? I was able to replicate the behaviour, but I am not sure, how the AltGr case should actually be handled. In case it helps, here are some things I looked at:

I verified that, on a german keyboard, AltGr is indeed translated into Left_CTRL && LEFT_ALT, tested for CMD, PS and WSL
It seems that the bug is related to non-passing tests. The following tests fail for me when switching to a german keyboard but pass on the english keyboard:
- InputEngingeTest:C0
- InputTest::TerminalInputModifierKeyTests#metadataSet3 up to and including set10

@lhecker Out of curiosity, I applied your first idea of replacing isAltGrPressed() with isAltPressed() && isCtrlPressed(), and verified that it:

works for CMD including @ and €, but not in PS or WSL
does actually not fix the non-passing tests
but instead breaks MouseInputTest::SgrModeTests#metadataSet20 for the english keyboard.

Even though I did not get very far in narrowing down the problem further I thought the information might be useful.

@MattKuhr commented on GitHub (May 18, 2019): Any progress on this? I was able to replicate the behaviour, but I am not sure, how the AltGr case **should** actually be handled. In case it helps, here are some things I looked at: - I verified that, on a german keyboard, AltGr is indeed translated into `Left_CTRL && LEFT_ALT`, tested for CMD, PS and WSL - It seems that the bug is related to non-passing tests. The following tests fail for me when switching to a german keyboard but pass on the english keyboard: - `InputEngingeTest:C0` - `InputTest::TerminalInputModifierKeyTests#metadataSet3` up to and including set10 @lhecker Out of curiosity, I applied your first idea of replacing `isAltGrPressed()` with ` isAltPressed() && isCtrlPressed()`, and verified that it: - works for CMD including @ and €, but not in PS or WSL - does actually not fix the non-passing tests - but instead breaks `MouseInputTest::SgrModeTests#metadataSet20` for the english keyboard. Even though I did not get very far in narrowing down the problem further I thought the information might be useful.

claunia commented

2026-01-30 22:03:01 +00:00

@lhecker commented on GitHub (May 19, 2019):

That's very interesting @MattKuhr. @ and € actually work for me both within PowerShell and WSL. 🤔
(Just to be 100% sure - This is my diff on the current master 67f68eb.)

@lhecker commented on GitHub (May 19, 2019): That's very interesting @MattKuhr. @ and € actually work for me both within PowerShell and WSL. 🤔 (Just to be 100% sure - [This is my diff](https://gist.github.com/lhecker/0cd7d8ea6213c8a250283b0058b10463) on the current master 67f68eb.)

claunia commented

2026-01-30 22:03:01 +00:00

@MattKuhr commented on GitHub (May 20, 2019):

It is indeed, I updated to the current master and tested it again. Now the special characters work, except for € in PS.

I am not sure what caused the behaviour I observed earlier, the exact same code changes were used. I am starting to think that I might have messed up something with the deployment while testing, although I tested multiple times, or some windows updates that got installed in the mean time had an effect.

This is a screen capture with the german keyboard set when testing on the current master:

I tested it on both Debug and Release (x64), Win 10.0.18362.116. I also tried changing the system language, which had no effect. It seems a little strange, that only in this one specific case the € is not translated correctly..

@MattKuhr commented on GitHub (May 20, 2019): It is indeed, I updated to the current master and tested it again. Now the special characters work, except for € in PS. I am not sure what caused the behaviour I observed earlier, the exact same code changes were used. I am starting to think that I might have messed up something with the deployment while testing, although I tested multiple times, or some windows updates that got installed in the mean time had an effect. This is a screen capture with the german keyboard set when testing on the current master: ![screenRec](https://user-images.githubusercontent.com/36934540/57990360-3d1d4900-7aa6-11e9-8d00-22be9022a564.gif) I tested it on both Debug and Release (x64), Win 10.0.18362.116. I also tried changing the system language, which had no effect. It seems a little strange, that only in this one specific case the € is not translated correctly..

claunia commented

2026-01-30 22:03:02 +00:00

@DHowett-MSFT commented on GitHub (May 20, 2019):

Say, does it start working in PowerShell if you first Remove-Module PSReadline? (Don't worry: it'll only affect your current session.) If so, we've got some ideas!

@DHowett-MSFT commented on GitHub (May 20, 2019): Say, does it start working in PowerShell if you first `Remove-Module PSReadline`? (Don't worry: it'll only affect your current session.) If so, we've got some ideas!

claunia commented

2026-01-30 22:03:02 +00:00

@mwidmann commented on GitHub (May 20, 2019):

@DHowett-MSFT I tested it with a build of yesterday's master checkout with no changes on a German keyboard layout in 18362.113 (language setting is English)

Alt Gr + q => Q, expected @
Alt Gr + < => <, expected |
Alt Gr + + => +, expected ~
Alt Gr + ß => ß , expected \
Alt Gr + 2 => 2 , expected ²
Alt Gr + 3 => 3 , expected ³
Alt Gr + e => E , expected €

For regular characters Alt Gr works like shift. Any other character is left on the value without modifier.

@mwidmann commented on GitHub (May 20, 2019): @DHowett-MSFT I tested it with a build of yesterday's master checkout with no changes on a German keyboard layout in 18362.113 (language setting is English) `Alt Gr + q` => `Q`, expected `@` `Alt Gr + <` => `<`, expected `|` `Alt Gr + +` => `+`, expected `~` `Alt Gr + ß` => `ß` , expected `\` `Alt Gr + 2` => `2` , expected `²` `Alt Gr + 3` => `3` , expected `³` `Alt Gr + e` => `E` , expected `€` For regular characters Alt Gr works like shift. Any other character is left on the value without modifier.

claunia commented

2026-01-30 22:03:02 +00:00

@MattKuhr commented on GitHub (May 20, 2019):

@DHowett-MSFT It does actually 😃

The other keys keep working. Also, previously the tiny 3 would be written as normal 3, now it appears correctly, as you can see in the screenshot below.

@MattKuhr commented on GitHub (May 20, 2019): @DHowett-MSFT It does actually 😃 The other keys keep working. Also, previously the tiny 3 would be written as normal 3, now it appears correctly, as you can see in the screenshot below. ![image](https://user-images.githubusercontent.com/36934540/58006470-77a7d580-7ae8-11e9-9c7d-120ab0e69e3f.png)

claunia commented

2026-01-30 22:03:03 +00:00

@tumik commented on GitHub (May 20, 2019):

Hi,

Just here to tell this also affects the Finnish QWERTY layout, making all AltGr combinations like @, |, {}, [], ~, \ etc. unusable.

All of those seem to work fine with the patch from @lhecker in WSL, cmd and powershell. Thanks @lhecker !

@tumik commented on GitHub (May 20, 2019): Hi, Just here to tell this also affects the Finnish QWERTY layout, making all AltGr combinations like @, |, {}, [], ~, \ etc. unusable. All of those seem to work fine with the patch from @lhecker in WSL, cmd and powershell. Thanks @lhecker !

claunia commented

2026-01-30 22:03:03 +00:00

@plop28 commented on GitHub (May 21, 2019):

Hello, it works for the French Azerty keyboard layout too. Thanks @lhecker

@plop28 commented on GitHub (May 21, 2019): Hello, it works for the French Azerty keyboard layout too. Thanks @lhecker

claunia commented

2026-01-30 22:03:03 +00:00

@DaveSenn commented on GitHub (May 22, 2019):

Having problem with Alt Gr combinations e.g. “Alt Gr + <” (Backslash, but results in “<”) on a swiss german keyboard.

@DaveSenn commented on GitHub (May 22, 2019): Having problem with Alt Gr combinations e.g. “Alt Gr + <” (Backslash, but results in “<”) on a swiss german keyboard.

claunia commented

@DHowett-MSFT commented on GitHub (May 22, 2019):

I've updated the title of this issue to make it more obvious to passerby what it is tracking.

@DHowett-MSFT commented on GitHub (May 22, 2019): I've updated the title of this issue to make it more obvious to passerby what it is tracking.

claunia commented

@sba923 commented on GitHub (May 23, 2019):

@zadjii-msft I found your (?) AltGr related comment in terminalInput.cpp.
Thus I replaced...
660d31ac52/src/terminal/input/terminalInput.cpp (L415-L419)
with...
if (keyEvent.IsAltPressed() && keyEvent.IsCtrlPressed())
{
return false;
}
...and it works! For now. 😅

This change also gets me a usable AltGr on my French keyboard. Tested so far with CMD, Windows PowerShell 5.1, PowerShell Core 6.2.1 (both with the unofficial PSReadline 2.0.0beta4 that one needs to work in VScode)

@sba923 commented on GitHub (May 23, 2019): > @zadjii-msft I found your (?) AltGr related comment in terminalInput.cpp. > Thus I replaced... > https://github.com/microsoft/Terminal/blob/660d31ac522186e615ec243de2a434c273464828/src/terminal/input/terminalInput.cpp#L415-L419 > with... > if (keyEvent.IsAltPressed() && keyEvent.IsCtrlPressed()) > { > return false; > } > ...and it works! For now. 😅 This change also gets me a usable AltGr on my French keyboard. Tested so far with CMD, Windows PowerShell 5.1, PowerShell Core 6.2.1 (both with the unofficial PSReadline 2.0.0beta4 that one needs to work in VScode)

claunia commented

@MattKuhr commented on GitHub (May 23, 2019):

This change also gets me a usable AltGr on my French keyboard. Tested so far with CMD, Windows PowerShell 5.1, PowerShell Core 6.2.1 (both with the unofficial PSReadline 2.0.0beta4 that one needs to work in VScode)

I checked my PSReadline version and upgraded from 2.0.0 to 2.0.0-beta4 and that did the trick, now € and ³ are also working correctly in PS, both 5.1 and 6.2.1. 😄

Though I did find another bug that also seems to be related to PSReadline, but not to AltGr or keyboard layout directly. As you can see below, in Terminal CTRL 2 is translated to " and CTRL 7 (on GER layout, on US it's CTRL /) to ^_

For the first case, Removing PSReadline does the trick, for the second it does not. I tried the other number and special char keys, but these two were the only two instances I was able to find so far. The behaviour is identical for 5.1 and 6.2.1. PSReadline is 2.0.0beta4.

Should we open a seperate issue for this?

@MattKuhr commented on GitHub (May 23, 2019): > This change also gets me a usable AltGr on my French keyboard. Tested so far with CMD, Windows PowerShell 5.1, PowerShell Core 6.2.1 (both with the unofficial PSReadline 2.0.0beta4 that one needs to work in VScode) I checked my PSReadline version and upgraded from 2.0.0 to 2.0.0-beta4 and that did the trick, now € and ³ are also working correctly in PS, both 5.1 and 6.2.1. 😄 Though I did find another bug that also seems to be related to PSReadline, but not to AltGr or keyboard layout directly. As you can see below, in Terminal `CTRL 2` is translated to `"` and `CTRL 7` (on GER layout, on US it's `CTRL /`) to `^_` ![screenRec](https://user-images.githubusercontent.com/36934540/58259049-1431d800-7d74-11e9-8060-c0c4b46e4032.gif) For the first case, Removing PSReadline does the trick, for the second it does not. I tried the other number and special char keys, but these two were the only two instances I was able to find so far. The behaviour is identical for 5.1 and 6.2.1. PSReadline is 2.0.0beta4. Should we open a seperate issue for this?

claunia commented

@rjfmachado commented on GitHub (May 24, 2019):

I also see related issues on a Portuguese (Portugal) keyboard.
Expected: Alt Gr + 2/3/4/7/8/9/0 should output @ £ § { [ ] }, Alt Gr + e should get €

Windows Terminal:
-PS Core: Alt Gr + digit triggers PSReadline DigitFunction, except 7 outputs ^_
-PS Core: Alt Gr + € does nothing
-Windows Powershell: Same as PS Core
-CMD: Alt Gr + digit outputs the digit, except 7 outputs ^_
-CMD: Alt Gr + e outputs E

Built-in console:
PS Core: Alt Gr + 2/3/4/7/8/9/0 output @ £ § { [ ] }, Alt Gr + E does nothing
Windows PowerShell: Same as PS Core
CMD - All works

Windows 10 1903 18362.116
PS Core 6.2
Windows Terminal 0.1.1431.0
PSReadline 2.0.0

@rjfmachado commented on GitHub (May 24, 2019): I also see related issues on a Portuguese (Portugal) keyboard. Expected: Alt Gr + 2/3/4/7/8/9/0 should output @ £ § { [ ] }, Alt Gr + e should get € Windows Terminal: -PS Core: Alt Gr + digit triggers PSReadline DigitFunction, except 7 outputs ^_ -PS Core: Alt Gr + € does nothing -Windows Powershell: Same as PS Core -CMD: Alt Gr + digit outputs the digit, except 7 outputs ^_ -CMD: Alt Gr + e outputs E Built-in console: PS Core: Alt Gr + 2/3/4/7/8/9/0 output @ £ § { [ ] }, Alt Gr + E does nothing Windows PowerShell: Same as PS Core CMD - All works Windows 10 1903 18362.116 PS Core 6.2 Windows Terminal 0.1.1431.0 PSReadline 2.0.0

claunia commented

@DeChrist commented on GitHub (May 27, 2019):

A tried and true workaround when "Alt Gr" key combinations do not work is to use Alt+NumPad Code.

But, this does not work either !
#657 "Alt+Numpad not working"

I would advise that whomever addresses this one also addresses this closely related one.

@DeChrist commented on GitHub (May 27, 2019): A tried and true workaround when "Alt Gr" key combinations do not work is to use [Alt+NumPad Code](https://en.wikipedia.org/wiki/Alt_code). But, this does not work either ! #657 "Alt+Numpad not working" I would advise that whomever addresses this one also addresses this closely related one.

claunia commented

@TotiTolvukall commented on GitHub (May 28, 2019):

I can verify this as well for the Icelandic keyboard. We use AltGr to write these:
@|€{[]}\µ~`^

@TotiTolvukall commented on GitHub (May 28, 2019): I can verify this as well for the Icelandic keyboard. We use AltGr to write these: @|€{[]}\µ~`^

claunia commented

@MathiasMagnus commented on GitHub (May 28, 2019):

Just a side note: this issue comes up in just about all of the Microsoft command-line technologies. It came up already in OpenSSH, a similar issue came up in PSReadline, and here again, where none of the AltGr combinations don't work.

Every time I try something command-line, input issues always come up. I still cannot use PowerShell in remote sessions, because Home-End don't work, and they still don't work through SSH.

Somehow, this terminal-SSH-PSReadline triangle is cursed.

@MathiasMagnus commented on GitHub (May 28, 2019): Just a side note: this issue comes up in just about all of the Microsoft command-line technologies. It came up already in [OpenSSH](https://github.com/PowerShell/Win32-OpenSSH/issues/902), a similar issue came up in [PSReadline](https://github.com/PowerShell/PSReadLine/issues/700), and here again, where none of the AltGr combinations don't work. Every time I try something command-line, input issues always come up. I still cannot use PowerShell in remote sessions, because Home-End don't work, and they still don't work through SSH. Somehow, this terminal-SSH-PSReadline triangle is cursed.

claunia commented

@renatop7 commented on GitHub (May 31, 2019):

Here I'm using PT-BR keyboard layout.

To get / I use Alt Gr + Q

When using in Terminal it works like an undo command. It just retype my last command/letter/word

@renatop7 commented on GitHub (May 31, 2019): Here I'm using PT-BR keyboard layout. To get `/` I use `Alt Gr + Q` When using in Terminal it works like an undo command. It just retype my last command/letter/word

claunia commented

@krokofant commented on GitHub (May 31, 2019):

@MathiasMagnus

where none of the AltGr combinations don't work.

You mean to say that none of the AltGr combinations work?

@krokofant commented on GitHub (May 31, 2019): @MathiasMagnus > where none of the AltGr combinations don't work. You mean to say that none of the AltGr combinations work?

claunia commented

@thomaslevesque commented on GitHub (Jun 2, 2019):

Say, does it start working in PowerShell if you first Remove-Module PSReadline? (Don't worry: it'll only affect your current session.) If so, we've got some ideas!

Doesn't work for me (French AZERTY layout)

@thomaslevesque commented on GitHub (Jun 2, 2019): > Say, does it start working in PowerShell if you first `Remove-Module PSReadline`? (Don't worry: it'll only affect your current session.) If so, we've got some ideas! Doesn't work for me (French AZERTY layout)

claunia commented

@Hedrauta commented on GitHub (Jun 11, 2019):

so..... any new ideas? because the fix ...

if (keyEvent.IsAltPressed() && keyEvent.IsCtrlPressed())
{
    return false;
}
...

didnt worked for me <.<

Edit:

Isn't it smarter, to detect the main keyboard language, which is defined on the machine, and then do the rebind-stuff @microsoft ?

@Hedrauta commented on GitHub (Jun 11, 2019): so..... any new ideas? because the fix ... > > ```c++ > if (keyEvent.IsAltPressed() && keyEvent.IsCtrlPressed()) > { > return false; > } > ... didnt worked for me <.< Edit: Isn't it smarter, to detect the main keyboard language, which is defined on the machine, and then do the rebind-stuff @microsoft ?

claunia commented

@sba923 commented on GitHub (Jun 12, 2019):

@Hedrauta weird that the code change doesn't work for you. What keyboard layout are you using? What does Ctrl+Alt+xxx do for you in a normal CMD for values of xxx that are used in combination with AltGr? As far as I can remember, Ctrl+Alt should always be equivalent to AltGr...

@sba923 commented on GitHub (Jun 12, 2019): @Hedrauta weird that the code change doesn't work for you. What keyboard layout are you using? What does `Ctrl+Alt+xxx` do for you in a normal CMD for values of `xxx` that are used in combination with AltGr? As far as I can remember, `Ctrl+Alt` should always be equivalent to `AltGr`...

claunia commented

@fefrei commented on GitHub (Jun 12, 2019):

So, to collect some test data: For me, the patch by @lhecker seems to work fine. This is on a German keyboard layout:

Terminal	`Alt Gr`+`ß?\`	`Strg`+`Alt`+`ß?\`
Legacy `cmd.exe`	`\`	`\`
Legacy `pwsh.exe`	`\`	`\`
Windows Terminal, `master`, `cmd.exe`	`ß`	`ß`
Windows Terminal, `master`, `pwsh.exe`	(nothing)	(nothing)
Windows Terminal, `master` + Patch by @lhecker, `cmd.exe`	`\`	`\`
Windows Terminal, `master` + Patch by @lhecker, `pwsh.exe`	`\`	`\`

@fefrei commented on GitHub (Jun 12, 2019): So, to collect some test data: For me, the patch by @lhecker seems to work fine. This is on a German keyboard layout: Terminal | <kbd>Alt Gr</kbd>+<kbd>ß?\\</kbd> | <kbd>Strg</kbd>+<kbd>Alt</kbd>+<kbd>ß?\\</kbd> -|-|- Legacy `cmd.exe` | `\` | `\` Legacy `pwsh.exe` | `\` | `\` Windows Terminal, `master`, `cmd.exe` | `ß` | `ß` Windows Terminal, `master`, `pwsh.exe` | _(nothing)_ | _(nothing)_ Windows Terminal, `master` + [Patch by @lhecker](https://github.com/microsoft/terminal/issues/521#issuecomment-491407670), `cmd.exe` | `\` | `\` Windows Terminal, `master` + [Patch by @lhecker](https://github.com/microsoft/terminal/issues/521#issuecomment-491407670), `pwsh.exe` | `\` | `\`

claunia commented

@Ztarbox commented on GitHub (Jun 12, 2019):

same result as in https://github.com/microsoft/terminal/issues/521#issuecomment-501148984
with the Patch by @lhecker

But in pwsh the € - sign still isn't working on german layout.

cmd:
C:\Users\jkann>2² 3³ 7{ 8[ 9] 0} ß\ +~ <| Q@ E€
pwsh:
PS C:\Users\jkann> 2² 33 7{ 8[ 9] 0} ß\ +~ <| Q@ E

@Ztarbox commented on GitHub (Jun 12, 2019): same result as in https://github.com/microsoft/terminal/issues/521#issuecomment-501148984 with the [Patch by @lhecker](https://github.com/microsoft/terminal/issues/521#issuecomment-491407670) But in `pwsh` the € - sign still isn't working on german layout. cmd: `C:\Users\jkann>2² 3³ 7{ 8[ 9] 0} ß\ +~ <| Q@ E€` pwsh: `PS C:\Users\jkann> 2² 33 7{ 8[ 9] 0} ß\ +~ <| Q@ E`

claunia commented

@renatop7 commented on GitHub (Jun 12, 2019):

@Hedrauta weird that the code change doesn't work for you. What keyboard layout are you using? What does Ctrl+Alt+xxx do for you in a normal CMD for values of xxx that are used in combination with AltGr? As far as I can remember, Ctrl+Alt should always be equivalent to AltGr...

It didn't helped me either...
I even tried to make my own workaround based on that code but no luck so far...

I'm using PT-BR keyboard layout, trying the following combination:

CMD, Powershell and WSL.exe
AltGr + Q = /

When using the Windows Terminal
WSL: AltGr + Q = works like an undo command, it rewrites my last typed characters.
Powershell, CMD: AltGr + Q = produces this strange char prints like ^_

Edit:
To help visualize:

The correct input should be
AltGr + Q = /
AltGr + W = ?
AltGr + [ = ª
AltGr + ] = º

@renatop7 commented on GitHub (Jun 12, 2019): > @Hedrauta weird that the code change doesn't work for you. What keyboard layout are you using? What does `Ctrl+Alt+xxx` do for you in a normal CMD for values of `xxx` that are used in combination with AltGr? As far as I can remember, `Ctrl+Alt` should always be equivalent to `AltGr`... It didn't helped me either... I even tried to make my own workaround based on that code but no luck so far... I'm using PT-BR keyboard layout, trying the following combination: CMD, Powershell and WSL.exe `AltGr + Q` = `/` When using the Windows Terminal WSL: `AltGr + Q` = works like an undo command, it rewrites my last typed characters. Powershell, CMD: `AltGr + Q` = produces this strange char `` prints like `^_` Edit: To help visualize: ![terminal_keyboard_problem](https://user-images.githubusercontent.com/4468986/59365611-35e90400-8d0f-11e9-8e7f-11d8ed518e26.gif) The correct input should be `AltGr + Q` = `/` `AltGr + W` = `?` `AltGr + [` = `ª` `AltGr + ]` = `º`

claunia commented

@sba923 commented on GitHub (Jun 12, 2019):

@renatop7 what do you get with CtrlAlt instead of AltGr?

@sba923 commented on GitHub (Jun 12, 2019): @renatop7 what do you get with CtrlAlt instead of AltGr?

claunia commented

@renatop7 commented on GitHub (Jun 12, 2019):

@renatop7 what do you get with CtrlAlt instead of AltGr?

The same result

@renatop7 commented on GitHub (Jun 12, 2019): > @renatop7 what do you get with CtrlAlt instead of AltGr? The same result

claunia commented

@sba923 commented on GitHub (Jun 12, 2019):

And outside of Terminal i.e. in standard CMD or Windows Powershell or Powershell Core? Does CtrlAlt always behave like AltGr?

@sba923 commented on GitHub (Jun 12, 2019): And outside of Terminal i.e. in standard CMD or Windows Powershell or Powershell Core? Does CtrlAlt always behave like AltGr?

claunia commented

@renatop7 commented on GitHub (Jun 12, 2019):

And outside of Terminal i.e. in standard CMD or Windows Powershell or Powershell Core? Does CtrlAlt always behave like AltGr?

Yes, outside the Terminal it works perfectly.
Using with AltGr or Ctrl + Alt I get the expected result.

@renatop7 commented on GitHub (Jun 12, 2019): > And outside of Terminal i.e. in standard CMD or Windows Powershell or Powershell Core? Does CtrlAlt always behave like AltGr? Yes, outside the Terminal it works perfectly. Using with AltGr or Ctrl + Alt I get the expected result.

claunia commented

@Hedrauta commented on GitHub (Jun 16, 2019):

fetched 15 mins ago: no working at all
well, do microsoft even work on a solution related to this issue?

@Hedrauta weird that the code change doesn't work for you. What keyboard layout are you using? What does Ctrl+Alt+xxx do for you in a normal CMD for values of xxx that are used in combination with AltGr? As far as I can remember, Ctrl+Alt should always be equivalent to AltGr...

Uhm, Standard German one?. here a screen from how it looks like: https://i.imgur.com/mvgHkxi.png
i will try to type the key through a macro.... testing

it's like, my left alt is Shift, not Alt ...
tried Result
Ctrl+Q ^Q
CTRL+Alt+Q Q
just Q q
Alt+Q Q

Will try gif it, updating comment then
Edit: while trying to gif it, i realized, that my Alt-Key is recognized wrong.... anyone knows, where the virtual keys are defined? will look into it too ;) but i'm not that experienced on c++ or.... any coding ;)

@Hedrauta commented on GitHub (Jun 16, 2019): fetched 15 mins ago: no working at all well, do microsoft even work on a solution related to this issue? > > @Hedrauta weird that the code change doesn't work for you. What keyboard layout are you using? What does `Ctrl+Alt+xxx` do for you in a normal CMD for values of `xxx` that are used in combination with AltGr? As far as I can remember, `Ctrl+Alt` should always be equivalent to `AltGr`... Uhm, Standard German one?. here a screen from how it looks like: https://i.imgur.com/mvgHkxi.png i will try to type the key through a macro.... testing it's like, my left alt is Shift, not Alt ... tried Result Ctrl+Q ^Q CTRL+Alt+Q Q just Q q Alt+Q Q Will try gif it, updating comment then Edit: while trying to gif it, i realized, that my Alt-Key is recognized wrong.... anyone knows, where the virtual keys are defined? will look into it too ;) but i'm not that experienced on c++ or.... any coding ;)

claunia commented

@Hedrauta commented on GitHub (Jun 17, 2019):

Just for me as a cpp noob, i checked several files, and i found the
C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\um\WinUser.h
So.... for german layouts, the VK_Menu doesnt exists, right? we just own the VK_LMENU, right?
i'll try some changes and do some testing... will edit in the results later
Edit 1: Building is taking long, like i rebuild my whole systems o.O
Edit 2: after build the whole thing, it's not working... but i realized, that VK_RMENU is AltGr, while VK_LMENU is the key we want to see pressed to get our @ or \
but VK_MENU looks also working, but it may be assigned wrong
This is kind of confusing me, will check this one after a clean fetch, rebuild and a nap

@Hedrauta commented on GitHub (Jun 17, 2019): Just for me as a cpp noob, i checked several files, and i found the C:\Program Files (x86)\Windows Kits\10\Include\10.0.17763.0\um\WinUser.h So.... for german layouts, the VK_Menu doesnt exists, right? we just own the VK_LMENU, right? i'll try some changes and do some testing... will edit in the results later Edit 1: Building is taking long, like i rebuild my whole systems o.O Edit 2: after build the whole thing, it's not working... but i realized, that VK_RMENU is AltGr, while VK_LMENU is the key we want to see pressed to get our @ or \ but VK_MENU looks also working, but it may be assigned wrong This is kind of confusing me, will check this one after a clean fetch, rebuild and a nap

claunia commented

@Morgy93 commented on GitHub (Jun 22, 2019):

For German keyboard layout it's even worse, because Alt Gr + Q which should just output @, deletes the current line input.
That doesn't happen with wsl, nor I see it configured for WT - so how does this happen?

@Morgy93 commented on GitHub (Jun 22, 2019): For [German keyboard layout](https://commons.wikimedia.org/wiki/File:KB_Germany.svg) it's even worse, because `Alt Gr + Q` which should just output `@`, deletes the current line input. That doesn't happen with wsl, nor I see it configured for WT - so how does this happen?

claunia commented

@KennethVanMele commented on GitHub (Jun 22, 2019):

Still a problem:
Keyboard: Belgian (point) AZERTY, works in normal shell
Winver: 18362.175
Terminal version: 0.2.1715.0

@KennethVanMele commented on GitHub (Jun 22, 2019): Still a problem: Keyboard: Belgian (point) AZERTY, works in normal shell Winver: 18362.175 Terminal version: 0.2.1715.0

claunia commented

@lhecker commented on GitHub (Jun 22, 2019):

I'd like to ask everyone to please refrain from commenting that they're also dealing with this issue.

By now it should be clear to everyone that this issue affects a broad amount of key combination and can result in an equally broad amount of unexpected side effects, for an equally broad amount of languages, windows version, keyboards, etc.
More than half of the comments are of a #metoo style, which doesn't help fixing this issue at all and
only makes helpful comments less visible.
What's actually missing and would be of great help is for a knowledgeable Windows developer to tackle this issue and submit a PR.

In the meantime everyone capable of compiling this project may feel free to replace this piece of code: ce4c6d6124/src/terminal/input/terminalInput.cpp (L392-L396)

with this experimental fix of mine:

if (keyEvent.IsAltPressed() && keyEvent.IsCtrlPressed())
{
    return false;
}

This should fix most of the key combinations for most keyboard languages, including e.g. characters like @{}[] on a German (or similar) keyboard.

P.S.: I'm not affiliated with Microsoft in any way or form and I'm writing this because I personally consider these "#metoo" comments as too noisy / unproductive. 🙂
P.P.S.: I'm sure some are wondering why I don't submit a PR myself. To quote myself: "I feel like my change is incorrect though. There must be a reason why not all characters are handled by WM_CHAR right?" Meaning I don't actually know what the downsides of the above fix are and how to do it properly.

@lhecker commented on GitHub (Jun 22, 2019): _I'd like to ask everyone to please refrain from commenting that they're also dealing with this issue._ By now it should be clear to everyone that this issue affects a broad amount of key combination and can result in an equally broad amount of unexpected side effects, for an equally broad amount of languages, windows version, keyboards, etc. More than half of the comments are of a #metoo style, which doesn't help fixing this issue at all and *only makes helpful comments less visible*. What's actually missing and would be of great help is for a knowledgeable Windows developer to tackle this issue and submit a PR. In the meantime everyone capable of compiling this project may feel free to replace this piece of code: https://github.com/microsoft/terminal/blob/ce4c6d6124c258c676b4eeac61a709c1fb3da459/src/terminal/input/terminalInput.cpp#L392-L396 with this experimental fix of mine: ```cpp if (keyEvent.IsAltPressed() && keyEvent.IsCtrlPressed()) { return false; } ``` This should fix most of the key combinations for most keyboard languages, including e.g. characters like `@{}[]` on a German (or similar) keyboard. P.S.: I'm not affiliated with Microsoft in any way or form and I'm writing this because I personally consider these "#metoo" comments as too noisy / unproductive. 🙂 P.P.S.: I'm sure some are wondering why I don't submit a PR myself. [To quote myself](https://github.com/microsoft/terminal/issues/521#issuecomment-491525058): "I feel like my change is incorrect though. There must be a reason why not all characters are handled by `WM_CHAR` right?" Meaning I don't actually know what the downsides of the above fix are and how to do it properly.

claunia commented

@NatoBoram commented on GitHub (Jun 22, 2019):

P.P.S.: I'm sure some are wondering why I don't submit a PR myself. To quote myself: "I feel like my change is incorrect though. There must be a reason why not all characters are handled by WM_CHAR right?" Meaning I don't actually know what the downsides of the above fix are and how to do it properly.

One way to know would be to submit a PR and get corrected by the team. It's a bit overkill, but I think it would make things move faster.

@NatoBoram commented on GitHub (Jun 22, 2019): > P.P.S.: I'm sure some are wondering why I don't submit a PR myself. To quote myself: "I feel like my change is incorrect though. There must be a reason why not all characters are handled by WM_CHAR right?" Meaning I don't actually know what the downsides of the above fix are and how to do it properly. One way to know would be to submit a PR and get corrected by the team. It's a bit overkill, but I think it would make things move faster.

claunia commented

@lhecker commented on GitHub (Jun 22, 2019):

@NatoBoram 😤👉 #1436

@lhecker commented on GitHub (Jun 22, 2019): @NatoBoram 😤👉 #1436

claunia commented

@HBelusca commented on GitHub (Jun 23, 2019):

Note that when using the example applications e.g. VtPipeTerm, alt-gr key works in there.

@HBelusca commented on GitHub (Jun 23, 2019): Note that when using the example applications e.g. VtPipeTerm, alt-gr key works in there.

claunia commented

@lhecker commented on GitHub (Jun 23, 2019):

@HBelusca VtPipeTerm is not based on the new UWP Terminal and thus won't have this issue.
You can read #1436 for one possible explanation of the underlying issue.

@lhecker commented on GitHub (Jun 23, 2019): @HBelusca VtPipeTerm is not based on the new UWP Terminal and thus won't have this issue. You can read #1436 for one possible explanation of the underlying issue.

claunia commented

@DHowett-MSFT commented on GitHub (Jun 23, 2019):

@lhecker it’s not based on Cascadia, but it uses the same underlying pseudoconsole implementation ... so it’s extremely useful to know that it doesn’t apply to all pseudoconsole consumers!

Thanks @HBelusca

@DHowett-MSFT commented on GitHub (Jun 23, 2019): @lhecker it’s not based on Cascadia, but it uses the same underlying pseudoconsole implementation ... so it’s extremely useful to know that it doesn’t apply to all pseudoconsole consumers! Thanks @HBelusca

claunia commented

@ifilgud commented on GitHub (Jun 23, 2019):

Special keys have worked for years in terminals and windows apps. Why do we have this problem now in 2019? Have you completely re-implemented the input system for the terminal program? I hope it was necessary to do that and re-introduce the bugs that were fixed years ago :s. This problem was typical in linux due to codepages, language keyboard mappings and windows-specific keys, but this critical bug is in the preview version of the application, which is available in the store and publicited everywhere

@ifilgud commented on GitHub (Jun 23, 2019): Special keys have worked for years in terminals and windows apps. Why do we have this problem now in 2019? Have you completely re-implemented the input system for the terminal program? I hope it was necessary to do that and re-introduce the bugs that were fixed years ago :s. This problem was typical in linux due to codepages, language keyboard mappings and windows-specific keys, but this critical bug is in the preview version of the application, which is available in the store and publicited everywhere

claunia commented

@patriksvensson commented on GitHub (Jun 23, 2019):

@ifilgud It's a preview version available in the store for preview reasons. This issue have been triaged and there is also a submitted PR for it, so no need to comment on this issue just to complain.

@patriksvensson commented on GitHub (Jun 23, 2019): @ifilgud It's a *preview* version available in the store for *preview* reasons. This issue have been triaged and there is also a submitted PR for it, so no need to comment on this issue just to complain.

claunia commented

@ifilgud commented on GitHub (Jun 23, 2019):

@patriksvensson I know I was mainly complaining and that is not "polite", but also asking for a technical reason to explaing the reason of a bug like this. I expected having some minor errors to fix in an almost finished version (preview), but not one that should'nt have existed in an evolution of a terminal, unless written from scratch and only tested in english (I guess that is the reason to not detect this in the first alpha version). I opened the terminal and tried to write "cd \" as the second command (the first was "dir"), and it just didn't work. As a software developer this impacted me a lot.

@ifilgud commented on GitHub (Jun 23, 2019): @patriksvensson I know I was mainly complaining and that is not "polite", but also asking for a technical reason to explaing the reason of a bug like this. I expected having some minor errors to fix in an almost finished version (preview), but not one that should'nt have existed in an evolution of a terminal, unless written from scratch and only tested in english (I guess that is the reason to not detect this in the first alpha version). I opened the terminal and tried to write "cd \\" as the second command (the first was "dir"), and it just didn't work. As a software developer this impacted me a lot.

claunia commented

@eloy-salamanca commented on GitHub (Jun 24, 2019):

@lhecker so far, so good, after applying your experimental fix. Many thanks!!

@eloy-salamanca commented on GitHub (Jun 24, 2019): @lhecker so far, so good, after applying your experimental fix. Many thanks!! ![image](https://user-images.githubusercontent.com/34095746/59999053-49766200-9661-11e9-8994-21dbb1ee4bbd.png)

claunia commented

@SweeD commented on GitHub (Jun 24, 2019):

Thank you very much for all ppl who pointed this out and already fixed it. 🌷

How frequent will the MS Store App be updated?
So when can we expect to have stuff fixed in the stores app?

Would love to work with the terminal but with German keyboard, you can't even write { } without altgr. 😅

@SweeD commented on GitHub (Jun 24, 2019): Thank you very much for all ppl who pointed this out and already fixed it. 🌷 How frequent will the MS Store App be updated? So when can we expect to have stuff fixed in the stores app? Would love to work with the terminal but with German keyboard, you can't even write `{ }` without altgr. 😅

claunia commented

@o-l-a-v commented on GitHub (Jun 24, 2019):

Got the same problem for Norwegian Bokmål (nb-NO) keyboard layout as well. Can't create [] or {} or $. PowerShell is basically broken without those.
Using UWP / Microsoft Store version 0.2.1715.0 on Windows 10 1903 18362.175.

@o-l-a-v commented on GitHub (Jun 24, 2019): Got the same problem for Norwegian Bokmål (nb-NO) keyboard layout as well. Can't create [] or {} or $. PowerShell is basically broken without those. Using UWP / Microsoft Store version 0.2.1715.0 on Windows 10 1903 18362.175.

claunia commented

@MathiasMagnus commented on GitHub (Jun 24, 2019):

hu_HU layout via AltGr: \ | & @ $ ; # <> {} [] I mean how often do I open braces, angle or squared brackets, backslash, pipe, dollar sign, hash mark, "at", "and", semi-colon... oh wait, every line?? :)

@MathiasMagnus commented on GitHub (Jun 24, 2019): hu_HU layout via AltGr: `\ | & @ $ ; # <> {} []` I mean how often do I open braces, angle or squared brackets, backslash, pipe, dollar sign, hash mark, "at", "and", semi-colon... oh wait, every line?? :)

claunia commented

@DHowett-MSFT commented on GitHub (Jun 24, 2019):

I'd like to ask everyone to please refrain from commenting that they're also dealing with this issue.

By now it should be clear to everyone that this issue affects a broad amount of key combination and can result in an equally broad amount of unexpected side effects, for an equally broad amount of languages, windows version, keyboards, etc.
More than half of the comments are of a #metoo style, which doesn't help fixing this issue at all and
only makes helpful comments less visible.

@DHowett-MSFT commented on GitHub (Jun 24, 2019): > _I'd like to ask everyone to please refrain from commenting that they're also dealing with this issue._ > > By now it should be clear to everyone that this issue affects a broad amount of key combination and can result in an equally broad amount of unexpected side effects, for an equally broad amount of languages, windows version, keyboards, etc. > More than half of the comments are of a #metoo style, which doesn't help fixing this issue at all and > _only makes helpful comments less visible_.

claunia commented

@Karl-WE commented on GitHub (Jun 25, 2019):

Update: Same thing happens with all digits when combined with Alt Gr.

how did you do this gif record?

@Karl-WE commented on GitHub (Jun 25, 2019): > Update: Same thing happens with all digits when combined with `Alt Gr`. how did you do this gif record?

claunia commented

@patriksvensson commented on GitHub (Jun 25, 2019):

@Karl-WE Look further down in the thread.

@DHowett-MSFT Might be a good idea to lock this thread with a message at the bottom

@patriksvensson commented on GitHub (Jun 25, 2019): @Karl-WE Look further down in the thread. @DHowett-MSFT Might be a good idea to lock this thread with a message at the bottom

claunia commented

@Karl-WE commented on GitHub (Jun 25, 2019):

While the terminal is very unusable for Powershell while this issue is alive
I would like to bring up a workaround for Windows 10 1903 for those that cannot refrain until fixed..

Workaround:
use Windows key + .
go to special character tab select your character
switch to Terminal and insert the character

@Karl-WE commented on GitHub (Jun 25, 2019): While the terminal is very unusable for Powershell while this issue is alive I would like to bring up a workaround for Windows 10 1903 for those that cannot refrain until fixed.. Workaround: use Windows key + . go to special character tab select your character switch to Terminal and insert the character

claunia commented

@DHowett-MSFT commented on GitHub (Jun 25, 2019):

Leaving it unlocked gives people a space to report each individual key that doesn’t work so that they stop filing individual issues about each individual key that doesn’t work. I’m torn.

@DHowett-MSFT commented on GitHub (Jun 25, 2019): Leaving it unlocked gives people a space to report each individual key that doesn’t work so that they stop filing individual _issues_ about each individual key that doesn’t work. I’m torn.

claunia commented

@saadanerdetbare commented on GitHub (Jun 26, 2019):

There might be more cases where special characters do not bahave as expected. If I want to make an @ character on a danish keyboard there are 3 ways to do it: Alt Gr + 2, Left Ctrl + Left Alt + 2, or Left Alt + Numpad 64
The 2 first options gives the result OP reported.
The last option does in powershell :
Onpres Left Alt + Numpad 64 digit-argument: 64
Onrelease Left Alt: 64 @ characters
In cmd
Onpres Left Alt + Numpad 64: 64
Onrelease Left Alt: @ resulting in 64@
In wsl
Onpres Left Alt + Numpad 64: (arg: 64)
Onrelease Left Alt: 64 @ characters

@saadanerdetbare commented on GitHub (Jun 26, 2019): There might be more cases where special characters do not bahave as expected. If I want to make an @ character on a danish keyboard there are 3 ways to do it: Alt Gr + 2, Left Ctrl + Left Alt + 2, or Left Alt + Numpad 64 The 2 first options gives the result OP reported. The last option does in powershell : Onpres Left Alt + Numpad 64 `digit-argument: 64` Onrelease Left Alt: 64 @ characters In cmd Onpres Left Alt + Numpad 64: `64` Onrelease Left Alt: `@` resulting in `64@` In wsl Onpres Left Alt + Numpad 64: `(arg: 64)` Onrelease Left Alt: 64 @ characters

claunia commented

@lhecker commented on GitHub (Jun 26, 2019):

Good point @saadanerdetbare!

Your Alt+Numpad issue seems to stem from fact that the new Terminal (Cascadia) sends appropriate escape codes to the shell when you enter these codes. But simultaneously another part of the application is also handling this case, translating the Alt+Numpad code into an appropriate character and inserting that into the shell. This leads to the funny side effect of your @ character being repeated 64 times (due to having sent the following bytes to the shell: \x1b6\x1b4@).

You can try this out by adding the following additional code between these two lines:

if (!inEventsToWrite.empty() && static_cast<KeyEvent*>(&*inEventsToWrite.front())->GetCharData() == '\x1b')
{
    return;
}

This will stop Cascadia from sending these escape codes into the shell. Afterwards your characters (e.g. @) will appear normally.
Alternatively you can remove this block of code for the same effect.

~~@saadanerdetbare It would be super awesome if you could create a separate issue detailing your problem, since this is a bug unrelated to AltGr functionality. 🙂~~
👉 #1401
Should've searched for other issues first. 🤦‍♂️

P.S.: I do have to say though that seeing an increased readiness of the community to debug these things themselves instead of relying on unknown others would make me personally very proud. 🙈🙂

@lhecker commented on GitHub (Jun 26, 2019): Good point @saadanerdetbare! Your Alt+Numpad issue seems to stem from fact that the new Terminal (Cascadia) sends appropriate escape codes to the shell when you enter these codes. *But* simultaneously another part of the application is _also_ handling this case, translating the Alt+Numpad code into an appropriate character and inserting that into the shell. This leads to the funny side effect of your @ character being repeated 64 times (due to having sent the following bytes to the shell: `\x1b6\x1b4@`). You can try this out by adding the following additional code between [these two lines](https://github.com/microsoft/terminal/blob/5dd1f8d38ab584314c682afacbefaccb6478d67c/src/cascadia/TerminalCore/Terminal.cpp#L57-L58): ```cpp if (!inEventsToWrite.empty() && static_cast<KeyEvent*>(&*inEventsToWrite.front())->GetCharData() == '\x1b') { return; } ``` This will stop Cascadia from sending these escape codes into the shell. Afterwards your characters (e.g. @) will appear normally. Alternatively you can remove [this block of code](https://github.com/microsoft/terminal/blob/5dd1f8d38ab584314c682afacbefaccb6478d67c/src/terminal/input/terminalInput.cpp#L425-L430) for the same effect. ~@saadanerdetbare It would be super awesome if you could create a separate issue detailing your problem, since this is a bug unrelated to AltGr functionality. 🙂~ 👉 #1401 Should've searched for other issues first. 🤦‍♂️ P.S.: I do have to say though that seeing an increased readiness of the community to debug these things themselves instead of relying on unknown others would make me personally very proud. 🙈🙂

claunia commented

@DHowett-MSFT commented on GitHub (Jun 26, 2019):

@saadanerdetbare hold off on filing a new issue, that one is #1401 😄

@DHowett-MSFT commented on GitHub (Jun 26, 2019): @saadanerdetbare hold off on filing a new issue, that one is #1401 :smile:

claunia commented

@solispauwels commented on GitHub (Jun 28, 2019):

I am still experience this on the preview app, I have a belgian keyboard, imposible to write @

@solispauwels commented on GitHub (Jun 28, 2019): I am still experience this on the preview app, I have a belgian keyboard, imposible to write @

claunia commented

@antoineco commented on GitHub (Jun 28, 2019):

@solispauwels you'll have to wait until the next release (or build the current master branch yourself for now).

@antoineco commented on GitHub (Jun 28, 2019): @solispauwels you'll have to wait until the [next release](https://github.com/microsoft/terminal/releases) (or build the current master branch yourself for now).

claunia commented

@maru-sama commented on GitHub (Jun 28, 2019):

Hi, I just tested this commit on a german keyboard and everything works apart from altgr-E which should print the € symbol. To be honest I do not really need this in a terminal that often but I thought I might mention it anyway. Others like altgr-m for µ work though.

Update: I think you can ignore that, the € symbol does not work in a standard powershell either so it does not seem to be the terminal's fault, should have checked this earlier.

@maru-sama commented on GitHub (Jun 28, 2019): Hi, I just tested this commit on a german keyboard and everything works apart from altgr-E which should print the € symbol. To be honest I do not really need this in a terminal that often but I thought I might mention it anyway. Others like altgr-m for µ work though. Update: I think you can ignore that, the € symbol does not work in a standard powershell either so it does not seem to be the terminal's fault, should have checked this earlier.

claunia commented

@sba923 commented on GitHub (Jun 28, 2019):

Everything seems to work here on a French keyboard: AltGr+é"'(-è_çà)=$e yields the expected ~#{[|`\^@]}¤€

@sba923 commented on GitHub (Jun 28, 2019): Everything seems to work here on a French keyboard: ``AltGr+é"'(-è_çà)=$e`` yields the expected ``~#{[|`\^@]}¤€``

claunia commented

@meuter commented on GitHub (Jun 29, 2019):

I'm using a French keyboard as well (but I'm in Belgium), and I'm having trouble with the AltGr+ characters. |#{}@ for instance do not work. I'm using the latest release from the windows store 0.2.1715.0 on Windows 10 v1903.

@meuter commented on GitHub (Jun 29, 2019): I'm using a French keyboard as well (but I'm in Belgium), and I'm having trouble with the AltGr+<xx> characters. |#{}@ for instance do not work. I'm using the latest release from the windows store 0.2.1715.0 on Windows 10 v1903.

claunia commented

@antoineco commented on GitHub (Jun 29, 2019):

@meuter you'll have to wait until the next release (or build the current master branch yourself for now).

@antoineco commented on GitHub (Jun 29, 2019): @meuter you'll have to wait until the [next release](https://github.com/microsoft/terminal/releases) (or build the current master branch yourself for now).

claunia commented

@sba923 commented on GitHub (Jun 29, 2019):

The fix from #1436 is not yet included in the preview version available on the Microsoft Store

@sba923 commented on GitHub (Jun 29, 2019): The fix from #1436 is not yet included in the preview version available on the Microsoft Store

claunia commented

@meuter commented on GitHub (Jun 29, 2019):

@antoineco @sba923 thanks, that's what I figured. I just cloned the repo. As soon as my vs2017 is finished with the update, I'm going to rebuild it from source :-)

@meuter commented on GitHub (Jun 29, 2019): @antoineco @sba923 thanks, that's what I figured. I just cloned the repo. As soon as my vs2017 is finished with the update, I'm going to rebuild it from source :-)

claunia commented

2026-01-30 22:03:14 +00:00

@DHowett-MSFT commented on GitHub (Jul 3, 2019):

Thanks everyone for working so hard on this and filling our inboxes with reports. Thanks specifically to @lhecker for submitting a fix! We just submitted it to the store with the v0.2.1831.0 servicing release. It may take some time for the store to process it.

@DHowett-MSFT commented on GitHub (Jul 3, 2019): Thanks everyone for working so hard on this and filling our inboxes with reports. Thanks specifically to @lhecker for submitting a fix! We just submitted it to the store with the v0.2.1831.0 servicing release. It may take some time for the store to process it.

claunia commented

@NatoBoram commented on GitHub (Jul 3, 2019):

We just submitted it to the store

So, from my experience with publishing apps to the Windows Store, it should take from 3 days to 3 weeks 😉

@NatoBoram commented on GitHub (Jul 3, 2019): > We just submitted it to the store So, from my experience with publishing apps to the Windows Store, it should take from 3 days to 3 weeks 😉

claunia commented

2026-01-30 22:03:14 +00:00

@appel1 commented on GitHub (Jul 3, 2019):

We just submitted it to the store

So, from my experience with publishing apps to the Windows Store, it should take from 3 days to 3 weeks 😉

Less than 6h it would seem. 😋

Anyways, on my Swedish keyboard all seems well now. 👍

@appel1 commented on GitHub (Jul 3, 2019): > We just submitted it to the store > > So, from my experience with publishing apps to the Windows Store, it should take from 3 days to 3 weeks 😉 Less than 6h it would seem. 😋 Anyways, on my Swedish keyboard all seems well now. 👍

claunia commented

2026-01-30 22:03:14 +00:00

@XanatosX commented on GitHub (Jul 3, 2019):

Works with the German keyboard now 👍

@XanatosX commented on GitHub (Jul 3, 2019): Works with the German keyboard now 👍

claunia commented

@vlj commented on GitHub (Jul 3, 2019):

It works with french keyboard with version 0.2.1831.0 ! thanks

@vlj commented on GitHub (Jul 3, 2019): It works with french keyboard with version 0.2.1831.0 ! thanks

claunia commented

@sba923 commented on GitHub (Jul 3, 2019):

It works with french keyboard with version 0.2.1831.0 ! thanks

Confirmed!

Great job!

@sba923 commented on GitHub (Jul 3, 2019): > It works with french keyboard with version 0.2.1831.0 ! thanks Confirmed! Great job!

claunia commented

@solispauwels commented on GitHub (Jul 3, 2019):

@DHowett-MSFT The v0.2.1831.0 seems to include this fix but, not others bug fixes as powerline fonts or copy/paste keybings, is this normal?

@solispauwels commented on GitHub (Jul 3, 2019): @DHowett-MSFT The v0.2.1831.0 seems to include this fix but, not others bug fixes as powerline fonts or copy/paste keybings, is this normal?

claunia commented

@HBelusca commented on GitHub (Jul 3, 2019):

I confirm that Alt-Gr works, but using instead Ctrl-Alt to access the same keyboard keys does not work reliably (if at all).

@HBelusca commented on GitHub (Jul 3, 2019): I confirm that Alt-Gr works, but using instead Ctrl-Alt to access the same keyboard keys does not work reliably (if at all).

claunia commented

@cyberixae commented on GitHub (Jul 3, 2019):

In version 0.2.1831.0 AltGr combinations now work with Finnish keyboard.

@cyberixae commented on GitHub (Jul 3, 2019): In version 0.2.1831.0 AltGr combinations now work with Finnish keyboard.

claunia commented

@DHowett-MSFT commented on GitHub (Jul 3, 2019):

@solispauwels the only fixes in version 0.2.1831.0 are the ones mentioned in the release notes.

@DHowett-MSFT commented on GitHub (Jul 3, 2019): @solispauwels the only fixes in version 0.2.1831.0 are the ones mentioned in the release notes.

claunia commented

@Karl-WE commented on GitHub (Jul 3, 2019):

Please know that a lot of 1803 or later OS may face a bug with Windows Store version 11905.1001.4.0
The store will "stack" apps as to be downloaded (refer image) but won't download the apps, even with automatic download enabled and the network is not a metered connection.

Affected users have to press "Check for updates" in Microsoft Store to eventually get a fixed Store App and to initiate all app downloads pending.

I confirm this issue to be fixed with the new version of Terminal. Many thanks.

@Karl-WE commented on GitHub (Jul 3, 2019): Please know that a lot of 1803 or later OS may face a bug with Windows Store version 11905.1001.4.0 The store will "stack" apps as to be downloaded (refer image) but won't download the apps, even with automatic download enabled and the network is not a metered connection. Affected users have to press "Check for updates" in Microsoft Store to eventually get a fixed Store App and to initiate all app downloads pending. ![image](https://user-images.githubusercontent.com/45657752/60612178-55cc8e80-9dc8-11e9-80e0-436bb883b09b.png) ![image](https://user-images.githubusercontent.com/45657752/60612229-6ed53f80-9dc8-11e9-8f3f-0dd186e82fa8.png) I confirm this issue to be fixed with the new version of Terminal. Many thanks.

claunia commented

@ViktorHofer commented on GitHub (Jul 8, 2019):

I can confirm as well this is fixed now. You might want to unpin the issue.

@ViktorHofer commented on GitHub (Jul 8, 2019): I can confirm as well this is fixed now. You might want to unpin the issue.

claunia commented

@ifilgud commented on GitHub (Jul 8, 2019):

It works except Euro key, which is AltGr+e, at least in spanish keyboard. The rest of combinations work properly

@ifilgud commented on GitHub (Jul 8, 2019): It works except Euro key, which is AltGr+e, at least in spanish keyboard. The rest of combinations work properly

claunia commented

@DeChrist commented on GitHub (Jul 8, 2019):

From @ifilgud

It works except Euro key, which is AltGr+e, at least in spanish keyboard. The rest of combinations work properly

Tested on Windows 10 1903 (18362.175) using latest version on 2019-07-08 using "Belgian (Period)" AZERTY keyboard.

Test result:

all combinations I have available on my keyboard, including the Euro (€) currency symbol, work in 2 of the 3 Consoles configured as default in Windows Terminal: PowerShell Core and 'cmd' (Windows Command Prompt)
Only in "Windows PowerShell" does the Euro symbol (€) not work
- However it does not work in the PowerShell Classic Console launched directly from Windows Start as well

Imo this is a new issue related to Windows PowerShell, not specific to Windows Terminal hosting that Console.

@DeChrist commented on GitHub (Jul 8, 2019): From @ifilgud > It works except Euro key, which is AltGr+e, at least in spanish keyboard. The rest of combinations work properly Tested on Windows 10 1903 (18362.175) using latest version on 2019-07-08 using "Belgian (Period)" AZERTY keyboard. **Test result:** - all combinations I have available on my keyboard, **including** the Euro (€) currency symbol, work in 2 of the 3 Consoles configured as default in Windows Terminal: PowerShell Core and 'cmd' (Windows Command Prompt) - Only in "Windows PowerShell" does the Euro symbol (€) **not** work - However it does not work in the PowerShell Classic Console launched directly from Windows Start **as well** Imo this is a new issue related to Windows PowerShell, not specific to Windows Terminal hosting that Console.

claunia commented

@HBelusca commented on GitHub (Jul 8, 2019):

I confirm @DeChrist observation. On the other hand, Ctrl-Alt + (Key) pressing does not work as expected (if one wants to use this combination instead of AltGr).

@HBelusca commented on GitHub (Jul 8, 2019): I confirm @DeChrist observation. On the other hand, Ctrl-Alt + (Key) pressing does not work as expected (if one wants to use this combination instead of AltGr).

claunia commented

@sba923 commented on GitHub (Jul 9, 2019):

Here on Windows 10 build 18362.175 running Windows Terminal Preview version 0.2.1831.0, with a French keyboard, AltGr+E does yield € in all of the following shells:

cmd
Windows PowerShell 5.1
PowerShell Core 6.2.1
PowerShell Core 7.0.0-preview.1

Can anyone with remaining AltGr problems in PowerShell check what version of PSReadLine they are running?

$psrl = Get-Module PSReadLine
$psrl.Version
$psrl.PrivateData.PSData['Prerelease']

@sba923 commented on GitHub (Jul 9, 2019): Here on Windows 10 build 18362.175 running Windows Terminal Preview version 0.2.1831.0, with a French keyboard, ``AltGr+E`` **does** yield ``€`` in **all** of the following shells: - cmd - Windows PowerShell 5.1 - PowerShell Core 6.2.1 - PowerShell Core 7.0.0-preview.1 Can anyone with remaining ``AltGr`` problems _in PowerShell_ check what version of ``PSReadLine`` they are running? ```` $psrl = Get-Module PSReadLine $psrl.Version $psrl.PrivateData.PSData['Prerelease'] ````

claunia commented

2026-01-30 22:03:18 +00:00

@HBelusca commented on GitHub (Jul 9, 2019):

@sba923 :

PS C:\Users\myself> $psrl = Get-Module PSReadLine
PS C:\Users\myself> $psrl.Version

Major  Minor  Build  Revision
-----  -----  -----  --------
2      0      0      -1

PS C:\Users\myself> $psrl.PrivateData.PSData['Prerelease']
beta2

@HBelusca commented on GitHub (Jul 9, 2019): @sba923 : ``` PS C:\Users\myself> $psrl = Get-Module PSReadLine PS C:\Users\myself> $psrl.Version Major Minor Build Revision ----- ----- ----- -------- 2 0 0 -1 PS C:\Users\myself> $psrl.PrivateData.PSData['Prerelease'] beta2 ```

claunia commented

@sba923 commented on GitHub (Jul 9, 2019):

@HBelusca could you please try:

disabling PSReadLine
upgrading to the latest beta4, see https://github.com/PowerShell/PSReadLine

@sba923 commented on GitHub (Jul 9, 2019): @HBelusca could you please try: 1. disabling PSReadLine 2. upgrading to the latest ``beta4``, see https://github.com/PowerShell/PSReadLine

claunia commented

2026-01-30 22:03:18 +00:00

@sphr2k commented on GitHub (Jul 11, 2019):

Windows 10 1903
Windows Terminal 0.2.1831.0
PowerShell v7 (which includes PSReadline 2.0.0-beta4)
German QWERTZ keyboard layout

✅ AltGr + Q → @
✅ AltGr + E → €
❌ Ctrl + Alt + Q → q

This is especially frustrating since there's another bug related to mstsc that Microsoft has been ignoring for at least a decade where AltGr + Q stops working if an RDP session is open. In these situations, Ctrl + Alt + Q still works, so many people use it as a workaround.

@sphr2k commented on GitHub (Jul 11, 2019): * Windows 10 1903 * Windows Terminal 0.2.1831.0 * PowerShell v7 (which includes PSReadline 2.0.0-beta4) * German QWERTZ keyboard layout ✅ `AltGr + Q` → @ ✅ `AltGr + E` → € ❌ `Ctrl + Alt + Q` → q This is especially frustrating since there's another bug related to `mstsc` that Microsoft has been ignoring for at least a decade where `AltGr + Q` stops working if an RDP session is open. In these situations, `Ctrl + Alt + Q` still works, so many people use it as a workaround.

claunia commented

@thorsig commented on GitHub (Jul 11, 2019):

What Microsoft SHOULD do is NOT TOUCH THE KEYBOARD STREAM.

The shell ( explorer.exe ) should catch whatever keypresses it needs and pass everything else downstream.
Terminal.exe should ultimately ONLY catch Alt-F4 - and perhaps not even that - explorer.exe really should catch that and apply to the active process.

Which means Terminal.exe should only take the keyboard stream and pass it along to the active child process. Nothing else.

CMD.exe [ command.com ] should know how to catch what it needs and then pass the rest onto its own children.

WSL should get as much raw input as possible. DON'T manhandle AltGr. Ctrl-Alt and AltGr are NOT the same keyboard sequences. In Linux there exist shortcuts using ctrl-alt-... that produce different results than AltGr-...

You have but ONE opportunity to do it properly. The first opportunity in almost 40 years. Please, do not waste that opportunity - Microsoft, I'm looking at you :)

@thorsig commented on GitHub (Jul 11, 2019): What Microsoft SHOULD do is NOT TOUCH THE KEYBOARD STREAM. The shell ( explorer.exe ) should catch whatever keypresses it needs and pass everything else downstream. Terminal.exe should ultimately ONLY catch Alt-F4 - and perhaps not even that - explorer.exe really should catch that and apply to the active process. Which means Terminal.exe should only take the keyboard stream and pass it along to the active child process. Nothing else. CMD.exe [ command.com ] should know how to catch what it needs and then pass the rest onto its own children. WSL should get as much raw input as possible. DON'T manhandle AltGr. Ctrl-Alt and AltGr are NOT the same keyboard sequences. In Linux there exist shortcuts using ctrl-alt-... that produce different results than AltGr-... You have but ONE opportunity to do it properly. The first opportunity in almost 40 years. Please, do not waste that opportunity - Microsoft, I'm looking at you :)

claunia commented

@DHowett-MSFT commented on GitHub (Jul 11, 2019):

@thorsig ah, if only we had had you around when the Win32 input stack was architected forty-odd years ago. Unfortunately, we didn’t, so there are two primary ways to receive keyboard input:

as characters, without modifiers (so we can’t detect ALT to send it across the terminal pipes) or keypress direction
as scan codes, which have modifiers and directions, but are really just representations of physical key locations

When you start looking below the operating system level, scan codes are the “as raw input as possible” mode. They do, however, require a little bit of cooking before they can be passed on to applications that require text input. (Edit to add:) Terminal applications really prefer their input as text. We can’t send scan codes across an SSH connection! Even if we could, the recipient would then itself need to understand the keyboard layout to do translation. Probably headless machines don’t have a keyboard layout. (/edit)

If it were as easy as “get the literal character they pressed and send it along,” you have to trust that we would be doing just that. We don’t engineer crazy solutions because we are crazy people! 😄

@DHowett-MSFT commented on GitHub (Jul 11, 2019): @thorsig ah, if only we had had you around when the Win32 input stack was architected forty-odd years ago. Unfortunately, we didn’t, so there are two primary ways to receive keyboard input: * as characters, without modifiers (so we can’t detect ALT to send it across the terminal pipes) or keypress direction * as scan codes, which have modifiers and directions, but are really just representations of _physical key locations_ When you start looking below the operating system level, scan codes _are_ the “as raw input as possible” mode. They do, however, require a little bit of cooking before they can be passed on to applications that require text input. (Edit to add:) Terminal applications really prefer their input as text. We can’t send scan codes across an SSH connection! Even if we could, the recipient would then _itself_ need to understand the keyboard layout to do translation. Probably headless machines don’t have a keyboard layout. (/edit) If it were as easy as “get the literal character they pressed and send it along,” you have to trust that we would be doing just that. We don’t engineer crazy solutions because we are crazy people! :smile:

claunia commented

@thorsig commented on GitHub (Jul 11, 2019):

Well, I was around although I might not have had much of a clue how to handle the input stream at that time.

However, Linux works with the raw keycodes by default, so that's no issue. Your example of an ssh connection is however flawed, since ssh is never executed directly by the terminal application - there is a shell inside (or a whole OS abstraction like WSL) that is responsible for what reaches the shell.

If what you are stating would be right, every application ever written for Windows (running on top of explorer) would have to implement their own intrinsic keyboard handling. They don't. Because it's taken care of upstream and downstream.

I've looked at the code and had my share of "SMH". Could I do it better? Given time, probably. Can I afford to bitch about it? Given that I don't have time to do it myself - probably not.

I still found it worth to mention, it is being over-engineered as is, and it will cause problems downstream at some point (probably sooner than later).

@thorsig commented on GitHub (Jul 11, 2019): Well, I was around although I might not have had much of a clue how to handle the input stream at that time. However, Linux works with the raw keycodes by default, so that's no issue. Your example of an ssh connection is however flawed, since ssh is never executed directly by the terminal application - there is a shell inside (or a whole OS abstraction like WSL) that is responsible for what reaches the shell. If what you are stating would be right, every application ever written for Windows (running on top of explorer) would have to implement their own intrinsic keyboard handling. They don't. Because it's taken care of upstream and downstream. I've looked at the code and had my share of "SMH". Could I do it better? Given time, probably. Can I afford to bitch about it? Given that I don't have time to do it myself - probably not. I still found it worth to mention, it is being over-engineered as is, and it will cause problems downstream at some point (probably sooner than later).

claunia commented

@paulstelian97 commented on GitHub (Jul 12, 2019):

Well, I was around although I might not have had much of a clue how to handle the input stream at that time.

However, Linux works with the raw keycodes by default, so that's no issue. Your example of an ssh connection is however flawed, since ssh is never executed directly by the terminal application - there is a shell inside (or a whole OS abstraction like WSL) that is responsible for what reaches the shell.

WSL doesn't do any particular sort of translation. conhost.exe or Windows terminal (or Gnome-terminal if you run a graphical app through, say, XMing) does the proper translation to send to the pty. And even the shell...it isn't the shell itself doing most of the work. It's the terminal driver and the app at the master end (which, again, is either conhost.exe, Windows Terminal, perhaps Cygwin Terminal if you are inclined, and the Linux terminal apps).

If what you are stating would be right, every application ever written for Windows (running on top of explorer) would have to implement their own intrinsic keyboard handling. They don't. Because it's taken care of upstream and downstream.

Most apps don't care about raw keyboard input actually. That is handled through some Win32 libraries in ways which are inherently lossy. They don't use raw keyboard input directly. Most apps only care about characters, besides games which may care about physical layout input exactly. Either way works just fine.

I've looked at the code and had my share of "SMH". Could I do it better? Given time, probably. Can I afford to bitch about it? Given that I don't have time to do it myself - probably not.

I still found it worth to mention, it is being over-engineered as is, and it will cause problems downstream at some point (probably sooner than later).

I suggest you look into Gnome-Terminal, the Linux analogue, and check whether it's simpler or more complex. I suspect more complex since X is actually weirder than the GDI32 or whichever windowing API is in use.

@paulstelian97 commented on GitHub (Jul 12, 2019): > Well, I was around although I might not have had much of a clue how to handle the input stream at that time. > > However, Linux works with the raw keycodes by default, so that's no issue. Your example of an ssh connection is however flawed, since ssh is never executed directly by the terminal application - there is a shell inside (or a whole OS abstraction like WSL) that is responsible for what reaches the shell. > WSL doesn't do any particular sort of translation. conhost.exe or Windows terminal (or Gnome-terminal if you run a graphical app through, say, XMing) does the proper translation to send to the pty. And even the shell...it isn't the shell itself doing most of the work. It's the terminal driver and the app at the master end (which, again, is either conhost.exe, Windows Terminal, perhaps Cygwin Terminal if you are inclined, and the Linux terminal apps). > If what you are stating would be right, every application ever written for Windows (running on top of explorer) would have to implement their own intrinsic keyboard handling. They don't. Because it's taken care of upstream and downstream. Most apps don't care about raw keyboard input actually. That is handled through some Win32 libraries in ways which are inherently lossy. They don't use raw keyboard input directly. Most apps only care about characters, besides games which may care about physical layout input exactly. Either way works just fine. > > I've looked at the code and had my share of "SMH". Could I do it better? Given time, probably. Can I afford to bitch about it? Given that I don't have time to do it myself - probably not. > > I still found it worth to mention, it is being over-engineered as is, and it will cause problems downstream at some point (probably sooner than later). I suggest you look into Gnome-Terminal, the Linux analogue, and check whether it's simpler or more complex. I suspect more complex since X is actually weirder than the GDI32 or whichever windowing API is in use.

claunia commented

@henrik-jensen commented on GitHub (Aug 3, 2019):

Is there a regression from 0.2.1831.0 ?
On Danish keyboard, Windows Terminal Preview v0.3.2142.0 does not respond to AltGr.

Windows Terminal (Preview)
Version: 0.3.2142.0
Microsoft Windows 1903 [Version 10.0.18362.267]

@henrik-jensen commented on GitHub (Aug 3, 2019): Is there a regression from [**0.2.1831.0**](https://github.com/microsoft/terminal/releases/tag/v0.2.1831.0) ? On Danish keyboard, Windows Terminal Preview [**v0.3.2142.0**](https://github.com/microsoft/terminal/releases/tag/v0.3.2142.0) does not respond to AltGr. Windows Terminal (Preview) Version: 0.3.2142.0 Microsoft Windows 1903 [Version 10.0.18362.267]

claunia commented

@saadanerdetbare commented on GitHub (Aug 3, 2019):

I have danish keyboard and v0.3.2142.0 Windows build 10.0.18362.239 It is an english operating system without any languagepacks. The Alt Gr special characters works here, the Ctrl + Alt sequence does not

@saadanerdetbare commented on GitHub (Aug 3, 2019): I have danish keyboard and v0.3.2142.0 Windows build 10.0.18362.239 It is an english operating system without any languagepacks. The Alt Gr special characters works here, the Ctrl + Alt sequence does not

claunia commented

@henrik-jensen commented on GitHub (Aug 3, 2019):

I have danish keyboard and v0.3.2142.0 Windows build 10.0.18362.239 It is an english operating system without any language packs. The Alt Gr special characters works here, the Ctrl + Alt sequence does not

My Os: Win10 Home 1903 Build 10.0.18362.267
Danish Operating System with additional US language pack installed though the danish language pack is default.
Hmm - Build 10.0.18362.267 vs 10.0.18362.239 - is there a clue there?!!!

@henrik-jensen commented on GitHub (Aug 3, 2019): > I have danish keyboard and v0.3.2142.0 Windows build 10.0.18362.239 It is an english operating system without any language packs. The Alt Gr special characters works here, the Ctrl + Alt sequence does not My Os: Win10 Home 1903 Build 10.0.18362.267 Danish Operating System with additional US language pack installed though the danish language pack is default. Hmm - Build 10.0.18362.267 vs 10.0.18362.239 - is there a clue there?!!!

claunia commented

@saadanerdetbare commented on GitHub (Aug 3, 2019):

My Os: Win10 Home 1903 Build 10.0.18362.267
Danish Operating System with additional US language pack installed though the danish language pack is default.
Hmm - Build 10.0.18362.267 vs 10.0.18362.239 - is there a clue there?!!!

To get all the details:
I am on
Win 10 Enterprise en-US 1903 build 18362.239
Danish keyboard, no language pack

@saadanerdetbare commented on GitHub (Aug 3, 2019): > My Os: Win10 Home 1903 Build 10.0.18362.267 > Danish Operating System with additional US language pack installed though the danish language pack is default. > Hmm - Build 10.0.18362.267 vs 10.0.18362.239 - is there a clue there?!!! To get all the details: I am on Win 10 Enterprise en-US 1903 build 18362.239 Danish keyboard, no language pack

claunia commented

@henrik-jensen commented on GitHub (Aug 3, 2019):

Just tried to login on an account with the US language pack as default,- installed terminal there and switched to danish keyboard to see if the chosen language pack had any influence, but no luck there.

@henrik-jensen commented on GitHub (Aug 3, 2019): Just tried to login on an account with the US language pack as default,- installed terminal there and switched to danish keyboard to see if the chosen language pack had any influence, but no luck there.

claunia commented

@henrik-jensen commented on GitHub (Aug 3, 2019):

Don't know if this might be a clue for somebody in the know but before upgrading to 1903 from 1809 the On Screen Keyboard ( c:\windows\system32\osk.exe ) showed the same behaviour in all conhost apps, cmd.exe, ubuntu/wsl and powershell.exe (ignoring the AltGr) but in 1903 this seems fixed.

@henrik-jensen commented on GitHub (Aug 3, 2019): Don't know if this might be a clue for somebody in the know but before upgrading to 1903 from 1809 the On Screen Keyboard ( `c:\windows\system32\osk.exe` ) showed the same behaviour in all conhost apps, cmd.exe, ubuntu/wsl and powershell.exe (ignoring the AltGr) but in 1903 this seems fixed.

claunia commented

@lhecker commented on GitHub (Aug 3, 2019):

I can confirm that some AltGr sequences won't work.
AltGrQ (= @) works for me, while e.g. AltGr8 (= [) doesn't.

I've built the store version v0.3.2142.0 locally to debug this issue. Because I was unable to figure out how to build the AzureConnector I've had to exclude it though: https://gist.github.com/lhecker/320662cb3fda70af1ca58eabf9f2579a
👉 Turns out that my locally built v0.3.2142.0 works just fine. All AltGr sequences work correctly.
Only the store version of the Terminal doesn't. Could the AzureConnector be at fault here, since I excluded it? (I mean I doubt it's the case, but just to be sure...)

@DHowett-MSFT @miniksa Can you (or someone) recheck the Store version of v0.3.2142.0 and compare it with locally built ones?

@lhecker commented on GitHub (Aug 3, 2019): I can confirm that _some_ <kbd>AltGr</kbd> sequences won't work. <kbd>AltGr</kbd><kbd>Q</kbd> (= `@`) works for me, while e.g. <kbd>AltGr</kbd><kbd>8</kbd> (= `[`) doesn't. I've built the store version v0.3.2142.0 locally to debug this issue. Because I was unable to figure out how to build the AzureConnector I've had to exclude it though: https://gist.github.com/lhecker/320662cb3fda70af1ca58eabf9f2579a 👉 Turns out that my locally built v0.3.2142.0 works just fine. All <kbd>AltGr</kbd> sequences work correctly. Only the store version of the Terminal doesn't. Could the AzureConnector be at fault here, since I excluded it? (I mean I doubt it's the case, but just to be sure...) @DHowett-MSFT @miniksa Can you (or someone) recheck the Store version of v0.3.2142.0 and compare it with locally built ones?

claunia commented

@MasMedIm commented on GitHub (Aug 3, 2019):

I have the same issue. The terminal is not usable with that problem since AltGr is a must. And why this thread is closed ? It should be a top priority issue.

@MasMedIm commented on GitHub (Aug 3, 2019): I have the same issue. The terminal is not usable with that problem since AltGr is a must. And why this thread is closed ? It should be a top priority issue.

claunia commented

@DHowett-MSFT commented on GitHub (Aug 3, 2019):

And why this thread is closed?

@MasMedIm You might notice upon closer inspection that we believed this bug to be fixed, and even released a version with the fix.

@lhecker that’s very unusual. The Azure connector shouldn’t have anything to do with this since it’s in a different layer (connection, not control)... but that is interesting regardless.

@DHowett-MSFT commented on GitHub (Aug 3, 2019): > And why this thread is closed? @MasMedIm You might notice upon closer inspection that we believed this bug to be fixed, and even released a version with the fix. @lhecker that’s very unusual. The Azure connector shouldn’t have anything to do with this since it’s in a different layer (connection, not control)... but that is interesting regardless.

claunia commented

@saadanerdetbare commented on GitHub (Aug 4, 2019):

Can you (or someone) recheck the Store version of v0.3.2142.0 and compare it with locally built ones?

The version I have where the AltGr special character do work is the store version

@saadanerdetbare commented on GitHub (Aug 4, 2019): > Can you (or someone) recheck the Store version of v0.3.2142.0 and compare it with locally built ones? The version I have where the AltGr special character do work is the store version

claunia commented

@sba923 commented on GitHub (Aug 4, 2019):

AltGr (~#{[|`\^@]}¤€) works fine here with a French keyboard, Windows 10 version 1903 build 18362.267, and Windows Terminal Preview 0.3.2142.0

@sba923 commented on GitHub (Aug 4, 2019): AltGr (``~#{[|`\^@]}¤€``) works fine here with a French keyboard, Windows 10 version 1903 build 18362.267, and Windows Terminal Preview 0.3.2142.0

claunia commented

2026-01-30 22:03:23 +00:00

@MasMedIm commented on GitHub (Aug 4, 2019):

@sba923 I have a French keyboard too and the same windows version. The AltGr combinations that do not work are : &~#{[|`^€ù\
My terminal is downloaded from the store too. I'll try to build it in local to see.

@MasMedIm commented on GitHub (Aug 4, 2019): @sba923 I have a French keyboard too and the same windows version. The AltGr combinations **that do not work** are : &~#{[|`\^€ù\\ My terminal is downloaded from the store too. I'll try to build it in local to see.

claunia commented

@henrik-jensen commented on GitHub (Aug 4, 2019):

Just to elaborate on my situation,- some AltGr + Key combinations actually does work while some doesn't.

Does not work:

Key	AltGr + Key, expected:
'2'	'@'
'3'	'£'
'4'	'$'
'7'	'{'
'8'	'['
'9'	']'

Works:

Key	AltGr + Key, expected:
'0'	'}'
'´'	'\|'
'<'	'\'
'¨'	'~'
'e'	'€'

Note: '´', '¨' are dead key types.

System: Windows 10 64bit Home 1903 Build 10.0.18362.267
Windows Terminal: Preview v0.3.2142.0 - Store version
Keyboard layout: Danish.

@henrik-jensen commented on GitHub (Aug 4, 2019): Just to elaborate on my situation,- some AltGr + Key combinations actually does work while some doesn't. ### Does not work: | Key | AltGr + Key, expected: | | ----- | ----------------------- | | '2' | '@' | | '3' | '£' | | '4' | '$' | | '7' | '{' | | '8' | '[' | | '9' | ']' | ### Works: | Key | AltGr + Key, expected: | | ----- | ----------------------- | | '0' | '}' | | '´' | '\|' | | '<' | '\\' | | '¨' | '~' | | 'e' | '€' | Note: '´', '¨' are dead key types. System: Windows 10 64bit Home 1903 Build 10.0.18362.267 Windows Terminal: Preview v0.3.2142.0 - Store version Keyboard layout: Danish.

claunia commented

2026-01-30 22:03:23 +00:00

@henrik-jensen commented on GitHub (Aug 4, 2019):

@MasMedIm, @sba923, @lhecker - Are your Windows Versions Home like mine?
Edit: Forget my question. I was about to start a wild goose chase there ;-), but @lhecker seems to have solved the regression!

@henrik-jensen commented on GitHub (Aug 4, 2019): @MasMedIm, @sba923, @lhecker - Are your Windows Versions Home like mine? Edit: Forget my question. I was about to start a wild goose chase there ;-), but @lhecker seems to have solved the regression!

claunia commented

2026-01-30 22:03:23 +00:00

@lhecker commented on GitHub (Aug 4, 2019):

@DHowett-MSFT @henrik-jensen et. al.: I found the cause for the regression. ¯\_(ツ)_/¯
...and it makes all of us here a bunch of morons for noticing earlier. 😂

The new profiles.json contains shortcuts of the Ctrl+Alt+[0-9] kind to quickly jump to Tab 1-10.
If you remove these shortcuts from your Settings file (Ctrl,) the regression is fixed.
Certain combinations like AltGrE for € sadly have never worked yet though and someone has to take the necessary time to fix this.

Due to the way how the old Windows APIs work, it's going to be difficult to reliably differentiate between CtrlAlt shortcuts and actual AltGr keypresses, but I'm going to check whether the situation can be improved somehow.

@lhecker commented on GitHub (Aug 4, 2019): @DHowett-MSFT @henrik-jensen et. al.: I found the cause for the regression. ¯\\\_(ツ)_/¯ ...and it makes all of us here a bunch of morons for noticing earlier. 😂 The new `profiles.json` contains shortcuts of the `Ctrl+Alt+[0-9]` kind to quickly jump to Tab 1-10. If you remove these shortcuts from your Settings file (<kbd>Ctrl</kbd><kbd>,</kbd>) the regression is fixed. Certain combinations like <kbd>AltGr</kbd><kbd>E</kbd> for `€` sadly have never worked yet though and someone has to take the necessary time to fix this. Due to the way how the old Windows APIs work, it's going to be difficult to reliably differentiate between <kbd>Ctrl</kbd><kbd>Alt</kbd> shortcuts and actual <kbd>AltGr</kbd> keypresses, but I'm going to check whether the situation can be improved somehow.

claunia commented

2026-01-30 22:03:24 +00:00

@henrik-jensen commented on GitHub (Aug 4, 2019):

@lhecker 🥇 👍
Confirmed. Jubii

Certain combinations like AltGr E for € sadly have never worked yet though and someone has to take the necessary time to fix this.

AltGr E -> '€' does work on my Danish keyboard layout. I'll try adding a German layout on mine to see if it's reproducible on my setup.

@henrik-jensen commented on GitHub (Aug 4, 2019): @lhecker 🥇 👍 Confirmed. Jubii > Certain combinations like AltGr E for `€` sadly have never worked yet though and someone has to take the necessary time to fix this. AltGr E -> '€' does work on my Danish keyboard layout. I'll try adding a German layout on mine to see if it's reproducible on my setup.

claunia commented

2026-01-30 22:03:24 +00:00

@thorsig commented on GitHub (Aug 4, 2019):

How about just biting the bullet? Keep the old CMD.EXE around for legacy (DOS) apps and design the new Terminal for the future only? Not that backwards compatibility isn't great - but sometimes you just have to cut ties...

@thorsig commented on GitHub (Aug 4, 2019): How about just biting the bullet? Keep the old CMD.EXE around for legacy (DOS) apps and design the new Terminal for the future only? Not that backwards compatibility isn't great - but sometimes you just _have_ to cut ties...

claunia commented

2026-01-30 22:03:24 +00:00

@henrik-jensen commented on GitHub (Aug 4, 2019):

@lhecker 🥇 👍
Confirmed. Jubii

Certain combinations like AltGr E for € sadly have never worked yet though and someone has to take the necessary time to fix this.

AltGr E -> '€' does work on my Danish keyboard layout. I'll try adding a German layout on mine to see if it's reproducible on my setup.

Installed German ~~Kezboard~~ ups, Keyboard :-) *, and AltGr E -> '€' works in this setup.

Edit: * 'z'/'y' are swapped on german/danish keyboards.

@henrik-jensen commented on GitHub (Aug 4, 2019): > @lhecker 🥇 👍 > Confirmed. Jubii > > > Certain combinations like AltGr E for `€` sadly have never worked yet though and someone has to take the necessary time to fix this. > > AltGr E -> '€' does work on my Danish keyboard layout. I'll try adding a German layout on mine to see if it's reproducible on my setup. Installed German ~Kezboard~ ups, Keyboard :-) *, and AltGr E -> '€' works in this setup. Edit: * 'z'/'y' are swapped on german/danish keyboards.

claunia commented

2026-01-30 22:03:25 +00:00

@saadanerdetbare commented on GitHub (Aug 4, 2019):

The new profiles.json contains shortcuts of the Ctrl+Alt+[0-9] kind to quickly jump to Tab 1-10.

For some reason these shortcuts are alt+[0-9] in my settings file and so I did not have the problem

@saadanerdetbare commented on GitHub (Aug 4, 2019): > The new `profiles.json` contains shortcuts of the `Ctrl+Alt+[0-9]` kind to quickly jump to Tab 1-10. For some reason these shortcuts are alt+[0-9] in my settings file and so I did not have the problem

claunia commented

2026-01-30 22:03:25 +00:00

@henrik-jensen commented on GitHub (Aug 4, 2019):

Some questions now occurs to me:

@lhecker Maybe we should make a new issue for the regression for discoverability/history and you can add your patch solution to that? Edit: Great - @lhecker made a pull request #2235
I wonder where the default ~~settings.json~~ profiles.json is generated. It's not a resource so I assume it's hard coded somewhere? Edit: found it CascadiaSettings.cpp L369
What alternative shortcuts should be chosen instead. Maybe the ones @saadanerdetbare has in his ~~settings.json~~ profiles.json (Were they the default in pre 0.3.2142.0? Edit: Seems so - #2014 )

@henrik-jensen commented on GitHub (Aug 4, 2019): Some questions now occurs to me: - @lhecker Maybe we should make a new issue for the regression for discoverability/history and you can add your patch solution to that? Edit: Great - @lhecker made a pull request #2235 - I wonder where the default ~settings.json~ `profiles.json` is generated. It's not a resource so I assume it's hard coded somewhere? Edit: found it [CascadiaSettings.cpp L369](https://github.com/microsoft/terminal/blob/0d8f2998d6fdfa6013854ea66ccf26ed34ba8de2/src/cascadia/TerminalApp/CascadiaSettings.cpp#L369) - What alternative shortcuts should be chosen instead. Maybe the ones @saadanerdetbare has in his ~settings.json~ `profiles.json` (Were they the default in pre 0.3.2142.0? Edit: Seems so - #2014 )

claunia commented

2026-01-30 22:03:25 +00:00

@saadanerdetbare commented on GitHub (Aug 4, 2019):

@lhecker @henrik-jensen that would make sense. I installed from the store right after it was released there and I have made some changes to profiles.json So if the update did not overwrite the file because it was custom and not default I did not get the Ctrl+Alt shortcuts

@saadanerdetbare commented on GitHub (Aug 4, 2019): @lhecker @henrik-jensen that would make sense. I installed from the store right after it was released there and I have made some changes to `profiles.json` So if the update did not overwrite the file because it was custom and not default I did not get the Ctrl+Alt shortcuts

claunia commented

@MasMedIm commented on GitHub (Aug 4, 2019):

@DHowett-MSFT @henrik-jensen et. al.: I found the cause for the regression. ¯_(ツ)_/¯
...and it makes all of us here a bunch of morons for noticing earlier. 😂

The new profiles.json contains shortcuts of the Ctrl+Alt+[0-9] kind to quickly jump to Tab 1-10.
If you remove these shortcuts from your Settings file (Ctrl,) the regression is fixed.
Certain combinations like AltGrE for € sadly have never worked yet though and someone has to take the necessary time to fix this.

Due to the way how the old Windows APIs work, it's going to be difficult to reliably differentiate between CtrlAlt shortcuts and actual AltGr keypresses, but I'm going to check whether the situation can be improved somehow.

Ty for the response, indeed it was the Ctrl+Alt+[0-9] settings

@MasMedIm commented on GitHub (Aug 4, 2019): > > > @DHowett-MSFT @henrik-jensen et. al.: I found the cause for the regression. ¯\_(ツ)_/¯ > ...and it makes all of us here a bunch of morons for noticing earlier. 😂 > > The new `profiles.json` contains shortcuts of the `Ctrl+Alt+[0-9]` kind to quickly jump to Tab 1-10. > If you remove these shortcuts from your Settings file (Ctrl,) the regression is fixed. > Certain combinations like AltGrE for `€` sadly have never worked yet though and someone has to take the necessary time to fix this. > > Due to the way how the old Windows APIs work, it's going to be difficult to reliably differentiate between CtrlAlt shortcuts and actual AltGr keypresses, but I'm going to check whether the situation can be improved somehow. Ty for the response, indeed it was the Ctrl+Alt+[0-9] settings

claunia commented

@henrik-jensen commented on GitHub (Aug 4, 2019):

@saadanerdetbare, Yeah, it was changed from your settings to the new ones here #2014 by @zadjii-msft

@henrik-jensen commented on GitHub (Aug 4, 2019): @saadanerdetbare, Yeah, it was changed from your settings to the new ones here #2014 by @zadjii-msft

claunia commented

@sba923 commented on GitHub (Aug 4, 2019):

I confirm the new shortcuts do break AltGr (~#{[|`\^@]}) on my French keyboard.

The reason some of us didn't see the regression is related to the 0.3 upgrade not overriding an existing profiles.json, that's documented in Windows Terminal Preview v0.3 Release:

Note: If you have previously installed the Terminal before this release, these key bindings will only appear by default once you delete your profiles.json and allow it to regenerate. You can save your original profiles.json elsewhere and copy over your customizations or just add these key bindings manually. We are aware this is not an ideal experience and are working to improve this.

One can use ctrl+alt+shift+digit, althought that's not very easy to key in...

@sba923 commented on GitHub (Aug 4, 2019): I confirm the new shortcuts do break AltGr (``~#{[|`\^@]}``) on my French keyboard. The reason some of us didn't see the regression is related to the 0.3 upgrade not overriding an existing ``profiles.json``, that's documented in [Windows Terminal Preview v0.3 Release](https://devblogs.microsoft.com/commandline/windows-terminal-preview-v0-3-release/): > Note: If you have previously installed the Terminal before this release, these key bindings will only appear by default once you delete your profiles.json and allow it to regenerate. You can save your original profiles.json elsewhere and copy over your customizations or just add these key bindings manually. We are aware this is not an ideal experience and are working to improve this. One can use ctrl+alt+shift+_digit_, althought that's not very easy to key in...

claunia commented