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

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.

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

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

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

I think this is a duplicate of #487.

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

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

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

@lhecker Awesome! Now this is actually usable 🎉

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

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

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,

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

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.

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

All AltGr keyboard combinations are affected by the same issue.

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.

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

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

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

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

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 !

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

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

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

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

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?

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

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.

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

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.

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

@MathiasMagnus

where none of the AltGr combinations don't work.

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

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)

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 ?

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

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

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

@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 what do you get with CtrlAlt instead of AltGr?

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

The same result

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

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.

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

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

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?

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

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

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 😤👉 #1436

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

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

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

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

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

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.

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?? :)

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

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

how did you do this gif record?

@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

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

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.

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

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

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

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

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

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.

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

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 you'll have to wait until the next release (or build the current master branch yourself for now).

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

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

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.

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 😉

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

Works with the German keyboard now 👍

It works with french keyboard with version 0.2.1831.0 ! thanks

It works with french keyboard with version 0.2.1831.0 ! thanks

Confirmed!

Great job!

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

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

In version 0.2.1831.0 AltGr combinations now work with Finnish keyboard.

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

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.

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

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

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.

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

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 :

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 could you please try:

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

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

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

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

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.

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]

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

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

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

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.

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.

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?

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.

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.

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

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

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

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.

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

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

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

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

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

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 )

@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

@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

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

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

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

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.

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

:tada: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

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!

Thanks for the confirmation!

You're very welcome!

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.

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.

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

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

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"

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)

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

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

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.

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