AltGR SEQUENCES DO NOT WORK -- Can't type any AltGr combinations in Windows Terminal

[patriksvensson]

Your Windows build number:
10.0.18362.86

What you're doing and what's happening:
Trying to enter the @ sign on a Swedish keyboard in a PowerShell console using Alt Gr + 2.
See animated gif:

What's wrong / what should be happening instead:
Windows terminal shows digit-argument instead of outputting the @ sign as expected.

It's possible this is a PEBKAC error somehow but the problem doesn't show up in the normal PowerShell console... 😓

[patriksvensson]

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

[zadjii-msft]

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.

[watermelonpizza]

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

[patriksvensson]

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

[watermelonpizza]

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

[DHowett-MSFT]

I think this is a duplicate of #487.

[DHowett-MSFT]

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

[jozsefsallai]

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

[lhecker]

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

[krokofant]

@lhecker Awesome! Now this is actually usable 🎉

[ghosty141]

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

[lhecker]

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? 😅

[sagood]

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,

[lhecker]

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.

[sagood]

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

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.

[sinni800]

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

[mKay00]

All AltGr keyboard combinations are affected by the same issue.

[sba923]

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

[lhecker]

@henrik-jensen I opened #2235.

@thorsig You've already been told what the state of affairs in the Windows API landscape is.
Especially given that e.g. bash on Linux (like most shells you might want to use on Windows in the future) does not receive raw keycodes, but rather regular text infused with escape sequences. Escape sequences that your terminal needs to generate from keyboard events. Your Linux shell does not handle raw keycodes. Your terminal does.
Before you continue this you should first understand how xterm and vt100 (and later) work.
And btw: key codes on Linux are also just a virtual (!= raw) abstraction over scancodes from your keyboard - see keymaps.5. The only difference is that on Windows it was decided ages ago that Ctrl+Alt is the same as AltGr, because some keyboards where lacking AltGr keys, but one still wanted to be able to press AltGr somehow. The people who decided this might be 60+ nowadays. Changing this is non-trivial and has only an insignificant benefit (since you can detect AltGr key presses in practice already anyways).

[sdhdez]

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

It is easier to use alt+digit and it is similar to the shortcuts in gnome-terminal.
It works on my French keyboard.

[DHowett-MSFT]

If you use Alt+digit, be aware that you won’t be able to send those keys into a console application.

[ghost]

🎉This issue was addressed in #2235, which has now been successfully released as Windows Terminal Preview v0.3.2171.0.:tada:

Handy links:

• Release Notes
• Store Download

[sba923]

AltGr (~#{[|`\^@]}¤€) works fine here with a French keyboard, Windows 10 version 1903 build 18362.267, Windows Terminal Preview 0.3.2171.0, and the tab-switching shortcuts set to Ctrl+Alt+digit.

Good job!

[DHowett-MSFT]

Thanks for the confirmation!

[sba923]

You're very welcome!

[henrik-jensen]

0.3.2171.0 fix confirmed for my system - Danish keyboard Win10 Home 1903 build 10.0.18362.267.
Deleted my profiles.json to get default settings and now AltGr also works for a new install ( I assume ).
Great job @lhecker and everybody else involved.

[beppler]

Hi I think I have this problem on version 0.7.

I can not enter the slash key on my keyboard either using the numeric keypad ou AltGr+Q (Brazilian ABTN2 keyboard of an Samsung laptop that doe not have the question mark/slash key).

Edit: I can not enter any AltGr key.

[beppler]

After remove an older version of PSReadline eveything is working now.

[sba923]

FWIW, I have written the attached PowerShell scripts to verify what versions of PSReadline are on my system / which one is active.

CheckPSReadLineStatus.zip

HTH

[hatvik]

To fix the same issue as beppler reported, do:

After remove an older version of PSReadline eveything is working now.

From elevated powershell Session do:

Install-Module -Name PowerShellGet -Force
Exit

From elevated cmd session do:
powershell -noprofile -command "Install-Module PSReadLine -Force -SkipPublisherCheck -AllowPrerelease"

[ilmax]

What's the status of this issue?
Because looking at the linked issues it seems fixed, but it's still not working for me. In order to print the ~ character on an Italian keyboard layout, I'm used to do Alt+126 but this has a different behavior depending on the type of the terminal, but in none of them I'm able to get the ~ character printed, while doing directly in the the underlying shell (git/cmd/powershell/wsl not embedded in the windows terminal) works as expected

This is happening to me with the latest version of the windows terminal, at the moment of writing is:

Windows Terminal (Preview)
Version: 0.8.10091.0)

[lhecker]

@ilmax I broke Alt+Numpad input in #3117. Now that #3117 had been merged and the associated issue been fixed, we could work on reintroducing numpad input into the code base.
I'd make this an optional, configurable behavior though, because I'm fairly certain that most potential users of the Terminal app won't benefit from it anymore. The app should thus default to sending all possible keyboard input to the shell so you can configure more advanced vim, etc. keybindings.
Implementing this should be a fair bit easier as soon as #4192 is merged. You'd have to add the additional logic right here and check whether the Alt key (and only the Alt key) is being held in states, while the vkey stems from the numpad as opposed to from the regular numeric keys. Feel free to submit a PR at any time! 🙂

[ilmax]

@lhecker thanks for the quick response, I just wanted to know the state of this because every issue I found was closed but the problem is still there.
Not sure I'll come up with a PR on this, I never looked at the code before 😄 so I really don't know where to start, despite your suggestion.

I just wanted to know how to fix my workflow for git rebase -i because now I have to open something like notepad++, type the ~ character, copy it and paste it in the terminal.

[DHowett-MSFT]

Just so I understand: you’re on a thread about AltGr with a question about alt+numpad sequences? This may be why all the threads you’re finding are closed: the AltGr problem is fixed.

I do believe we have a separate issue tracking alt+numpad input problems.

[ilmax]

Yep, you're right, sorry for the confusion. I think #657 may the the correct one