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

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

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.

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.

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

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:

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.

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.

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

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

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

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

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.

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

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

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.

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

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

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

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 😃

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

@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

@NatoBoram 😤👉 #1436

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)

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.

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.

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

@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! 😄

@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

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.

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

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

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

@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

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

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

All AltGr keyboard combinations are affected by the same issue.

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

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"

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

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

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…

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

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…

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

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?

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.

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

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

It works with french keyboard with version 0.2.1831.0 ! thanks

Confirmed!

Great job!

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

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

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

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

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

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

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 😉

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, cmd.exe	\	\
Windows Terminal, master + Patch by @lhecker, pwsh.exe	\	\

@MathiasMagnus

where none of the AltGr combinations don’t work.

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

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

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

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

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!

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.