Ctrl+Alt+&#39;char&#39; generates other chars then &#39;AltGr&#39; (Germany Layout) v0.11.1121.0 #7633

@zadjii-msft commented on GitHub (Apr 24, 2020):

@lhecker that would be much appreciated, thanks :) I'll throw you on the assigned to line. I wouldn't worry about it too much, in all my years I honestly have never used an AltGr key so it's hard for me to check any of this 😆

@zadjii-msft commented on GitHub (Apr 24, 2020): @lhecker that would be much appreciated, thanks :) I'll throw you on the assigned to line. I wouldn't worry about it too much, in all my years I honestly have never used an <kbd>AltGr</kbd> key so it's hard for me to check any of this 😆

claunia commented

@ghost commented on GitHub (May 5, 2020):

:tada:This issue was addressed in #5552, which has now been successfully released as Windows Terminal Release Candidate v0.11.1251.0 (1.0rc1).🎉

Handy links:

@ghost commented on GitHub (May 5, 2020): :tada:This issue was addressed in #5552, which has now been successfully released as `Windows Terminal Release Candidate v0.11.1251.0 (1.0rc1)`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v0.11.1251.0 (1.0rc1)) * [Store Download](https://www.microsoft.com/store/apps/9n0dx20hk701?cid=storebadge&ocid=badge)

claunia commented

@mintty commented on GitHub (May 13, 2020):

I think the idea that Ctrl+Alt should always be the same as AltGr is wrong. The purpose of these key combinations is not the same. AltGr effectively extends the basic keyboard layout, while plain Alt is a generic modifier.
Considering a German keyboard, Ctrl+Alt+W generates ESC ^W as most terminals users would expect. In analogy, Ctrl+Alt+Q should generate ESC ^Q. However, with this unfortunate change, it generates just @ which is inconsistent. It's actually the AltGr key that's supposed to provide access to @ on a German keyboard, and thus also e.g. to ESC ^@ by pressing Ctrl+Alt+AltGr+Q. This and other combinations of both Alt+AltGr do not work anymore with the change.

@mintty commented on GitHub (May 13, 2020): I think the idea that Ctrl+Alt should always be the same as AltGr is wrong. The purpose of these key combinations is not the same. AltGr effectively extends the basic keyboard layout, while plain Alt is a generic modifier. Considering a German keyboard, Ctrl+Alt+W generates `ESC ^W` as most terminals users would expect. In analogy, Ctrl+Alt+Q should generate `ESC ^Q`. However, with this unfortunate change, it generates just `@` which is inconsistent. It's actually the AltGr key that's supposed to provide access to `@` on a German keyboard, and thus also e.g. to `ESC ^@` by pressing Ctrl+Alt+AltGr+Q. This and other combinations of both Alt+AltGr do not work anymore with the change.

claunia commented

@Ztarbox commented on GitHub (May 13, 2020):

Hm. Probably this is a correct technical explanation. But by experience, every program or tool (Word, Excel, cmd, Notepad, VSCode, pwsh, ...) I use with a german keyboard layout generates an @ when I use Ctrl+Alt+Q or an € when I use Ctrl+Alt+E. So I also expect the Windows Terminal to do it the same way, no?

Probably it is an windows thing. Wikipedia states this about this topic:

The characters ², ³, {, [, ], }, , @, |, µ, ~, and € are accessed by holding the AltGr key and tapping the other key. The Alt key on the left will not access these additional characters. Alternatively Strg+Alt [Strg is the german Ctrl] and pressing the respective key also produce the alternative characters on some operating systems.

Source Wikipedia

After I found this, I also tested it in WSL2 (Ubuntu 18.04.3 LTS) and here the Ctrl+Alt combinations aren't working. So it really seems to be a Windows thing?

@Ztarbox commented on GitHub (May 13, 2020): Hm. Probably this is a correct technical explanation. But by experience, every program or tool (Word, Excel, cmd, Notepad, VSCode, pwsh, ...) I use with a german keyboard layout generates an `@` when I use `Ctrl+Alt+Q` or an `€` when I use `Ctrl+Alt+E`. So I also expect the Windows Terminal to do it the same way, no? Probably it is an windows thing. Wikipedia states this about this topic: > The characters ², ³, {, [, ], }, \, @, |, µ, ~, and € are accessed by holding the `AltGr` key and tapping the other key. The `Alt` key on the left will not access these additional characters. Alternatively `Strg+Alt` [Strg is the german Ctrl] and pressing the respective key also produce the alternative characters on some operating systems. Source [Wikipedia](https://en.wikipedia.org/w/index.php?title=German_keyboard_layout&oldid=932701218) After I found this, I also tested it in WSL2 (Ubuntu 18.04.3 LTS) and here the `Ctrl+Alt` combinations aren't working. So it really seems to be a Windows thing?

claunia commented

@lhecker commented on GitHub (May 13, 2020):

@mintty As you probably already know, Windows treats Ctrl+Alt as a substitute for AltGr.
For instance on a German keyboard AltGr+Q produces @ and Ctrl+Alt+Q is supposed to be a substitute for this. You should notice that other Windows applications will produce @ characters when you press Ctrl+Alt+Q. If a user can use Ctrl+Alt+Q in pretty much every other application, why shouldn't they be allowed to expect the same behavior from this app?

If you use an English keyboard layout you should notice that the Terminal app correctly produces ^[^Q if you press Ctrl+Alt+Q btw.

a9c9714 is the commit which broke this common Windows behavior and users rightfully complained. #5552 then reverted/fixed parts of a9c9714 which restored it.
Personally I'm on your side, because "according to the specs" AltGr is supposed to be the only key responsible for extending the basic keyboard layout. But right now there's no config setting like "Ctrl+LeftAlt is AltGr" in mintty which would allow one to chose the behavior they like. And until that's added #5552 is IMO a correct change which shouldn't be reverted.

@lhecker commented on GitHub (May 13, 2020): @mintty As you probably already know, [Windows treats Ctrl+Alt as a substitute for AltGr.](https://en.wikipedia.org/wiki/AltGr_key#Control_+_Alt_as_a_substitute) For instance on a German keyboard `AltGr+Q` produces `@` and `Ctrl+Alt+Q` is supposed to be a substitute for this. You should notice that other Windows applications will produce `@` characters when you press `Ctrl+Alt+Q`. If a user can use `Ctrl+Alt+Q` in pretty much every other application, why shouldn't they be allowed to expect the same behavior from this app? If you use an English keyboard layout you should notice that the Terminal app correctly produces `^[^Q` if you press `Ctrl+Alt+Q` btw. a9c9714 is the commit which broke this common Windows behavior and users rightfully complained. #5552 then reverted/fixed parts of a9c9714 which restored it. Personally I'm on your side, because "according to the specs" AltGr is supposed to be the only key responsible for extending the basic keyboard layout. _But_ right now there's no config setting like "Ctrl+LeftAlt is AltGr" in mintty which would allow one to chose the behavior they like. And until that's added #5552 is IMO a correct change which shouldn't be reverted.

claunia commented

@lhecker commented on GitHub (May 13, 2020):

@Ztarbox Yep it's 100% a Windows thing. If you use Linux/Ubuntu (without WSL), Ctrl+Alt+@ will produce ^[^Q instead of @, because Linux doesn't treat Ctrl+Alt as an alias for AltGr.

I config setting would be nice to have in the future, but it might be kinda hard to get the setting value inside the TerminalInput class. And how common are Ctrl+Alt combinations? If they are commonly used by others, it might be worth investigating this, but if they aren't... Well, I'll review any PR that comes my way. ¯\_(ツ)_/¯ 🙂

@lhecker commented on GitHub (May 13, 2020): @Ztarbox Yep it's 100% a Windows thing. If you use Linux/Ubuntu (without WSL), `Ctrl+Alt+@` will produce `^[^Q` instead of `@`, because Linux doesn't treat `Ctrl+Alt` as an alias for `AltGr`. I config setting would be nice to have in the future, but it might be kinda hard to get the setting value inside the `TerminalInput` class. And how common are Ctrl+Alt combinations? If they are commonly used by others, it might be worth investigating this, but if they aren't... Well, I'll review any PR that comes my way. ¯\\\_(ツ)_/¯ :slightly_smiling_face:

claunia commented

@mintty commented on GitHub (May 13, 2020):

But by experience, every program or tool ... generates an @ when I use Ctrl+Alt+Q or an € when I use Ctrl+Alt+E. So I also expect the Windows Terminal to do it the same way, no?

No, you cannot generally take experience from one program to another. Tools like Word have their own concepts, e.g. you can define Ctrl+Alt shortcuts in them, and they may have a simplified view on keyboard capabilites. For a terminal, on the other hand, Ctrl, Alt, and some others are modifiers that should be available in turn for terminal applications (e.g. emacs) in full flexibility, mediated through escape sequences generated by the terminal, which can only work reliably if those modified key presses are not overloaded by simplified interpretation.

Windows treats Ctrl+Alt as a substitute for AltGr. For instance on a German keyboard AltGr+Q produces @ and Ctrl+Alt+Q is supposed to be a substitute for this.

Do you have a reference for this claim? I doubt it. It's not a Windows thing, it's a Windows applications thing. And the instance that many applications do that (and actually do it wrong) does not make it better.

@mintty commented on GitHub (May 13, 2020): > But by experience, every program or tool ... generates an @ when I use Ctrl+Alt+Q or an € when I use Ctrl+Alt+E. So I also expect the Windows Terminal to do it the same way, no? No, you cannot generally take experience from one program to another. Tools like Word have their own concepts, e.g. you can define Ctrl+Alt shortcuts in them, and they may have a simplified view on keyboard capabilites. For a terminal, on the other hand, Ctrl, Alt, and some others are modifiers that should be available in turn for terminal applications (e.g. emacs) in full flexibility, mediated through escape sequences generated by the terminal, which can only work reliably if those modified key presses are not overloaded by simplified interpretation. > Windows treats Ctrl+Alt as a substitute for AltGr. For instance on a German keyboard AltGr+Q produces @ and Ctrl+Alt+Q is supposed to be a substitute for this. Do you have a reference for this claim? I doubt it. It's not a Windows thing, it's a Windows applications thing. And the instance that many applications do that (and actually do it wrong) does not make it better.

claunia commented

@Ztarbox commented on GitHub (May 13, 2020):

@mintty

No, you cannot generally take experience from one program to another.

I believe I can. If I could use this functionality for decades in almost every (windows based) program I was using, I assume the same functionality for other programs (also terminals - or are these shells? I always mix them up in my mind - like powershell or cmd where this functionality is working). When Apple invented the swipe to navigate - now everyone expects to navigate this way on mobile phones in every app.

Do you have a reference for this claim? I doubt it. It's not a Windows thing, it's a Windows applications thing.

Me and @lhecker both included links to wikipedia that both stated this Windows behavior, but I accept not everyone accepts wiki as a reference. So probably this is a prove? These are screenshots of the Windows On-Screen Keyboard. It shows the same layout change for Ctrl+Alt as well as AltGr when I press these on my physical keyboard (blue = pressed).

The On-Screen Keyboard shows always this behavior regardless if the program I use interprets Ctrl+Alt as AltGr or not.

@Ztarbox commented on GitHub (May 13, 2020): @mintty > No, you cannot generally take experience from one program to another. I believe I can. If I could use this functionality for decades in almost every (windows based) program I was using, I assume the same functionality for other programs (also terminals - or are these shells? I always mix them up in my mind - like powershell or cmd where this functionality is working). When Apple invented the swipe to navigate - now everyone expects to navigate this way on mobile phones in every app. > Do you have a reference for this claim? I doubt it. It's not a Windows thing, it's a Windows applications thing. Me and @lhecker both included links to wikipedia that both stated this Windows behavior, but I accept not everyone accepts wiki as a reference. So probably this is a prove? These are screenshots of the Windows On-Screen Keyboard. It shows the same layout change for `Ctrl+Alt` as well as `AltGr` when I press these on my physical keyboard (blue = pressed). ![image](https://user-images.githubusercontent.com/19167839/81806680-1c52cc80-951d-11ea-9c32-a8a2bfd9696c.png) ![image](https://user-images.githubusercontent.com/19167839/81806704-27a5f800-951d-11ea-808c-98e76ea1b7fd.png) The On-Screen Keyboard shows always this behavior regardless if the program I use interprets `Ctrl+Alt` as `AltGr` or not.

claunia commented

@mintty commented on GitHub (May 13, 2020):

We're not talking about swipes and other graphical or touch-sensitive interaction paradigms, we're talking about text-based terminals.

Me and @lhecker both included links to wikipedia that both stated this Windows behavior, but I accept not everyone accepts wiki as a reference.

In fact not, they're not a proof. So I took the occasion to make some small changes there, amended with entries in the "Talk" pages asking that "if anyone feels it should be reverted, please add a reference to an authoritative specification of that behaviour in Windows".
The on-screen keyboard intends to simplify input for certain people, so simplification may be appropriate there. It's not a "proof" either.

Let's take a look at MS Word: AltGr+E is € and by default Ctrl+Alt+E is €, too. But via Insert – Symbols you can define shortcuts and for example assign Æ to Ctrl+Alt+E. AltGr+E will then still generate €.
Now think about a terminal as reserving all such potential shorcuts for the optional usage by applications running in the terminal. It needs to do that generically because it cannot know what the respective applications wish to use. A terminal is not an end application, it's rather a platform for running text-based applications.

@mintty commented on GitHub (May 13, 2020): We're not talking about swipes and other graphical or touch-sensitive interaction paradigms, we're talking about text-based terminals. > Me and @lhecker both included links to wikipedia that both stated this Windows behavior, but I accept not everyone accepts wiki as a reference. In fact not, they're not a proof. So I took the occasion to make some small changes there, amended with entries in the "Talk" pages asking that "if anyone feels it should be reverted, please add a reference to an authoritative specification of that behaviour in Windows". The on-screen keyboard intends to simplify input for certain people, so simplification may be appropriate there. It's not a "proof" either. Let's take a look at MS Word: AltGr+E is € and by default Ctrl+Alt+E is €, too. But via Insert – Symbols you can define shortcuts and for example assign Æ to Ctrl+Alt+E. AltGr+E will then still generate €. Now think about a terminal as reserving all such potential shorcuts for the optional usage by applications running in the terminal. It needs to do that generically because it cannot know what the respective applications wish to use. A terminal is not an end application, it's rather a platform for running text-based applications.

claunia commented

@lhecker commented on GitHub (May 13, 2020):

Do you have a reference for this claim? I doubt it. It's not a Windows thing, it's a Windows applications thing. And the instance that many applications do that (and actually do it wrong) does not make it better.

"I doubt it."? Well I beg to differ! Both Ctrl+Alt+Q and AltGr+Q produce a character event containing "@" in Win32 and UWP applications. Feel free to test this yourself. I don't even know why I bothered to do so, but in fact I did write a demo application for you, so you don't have to: https://gist.github.com/lhecker/c437cf941531ce49f7e2b5706085dff3

You're making it painfully clear that you will absolutely not listen to anyone else's experience, so maybe the above <100 LOC will prove to you somehow, that...
Yes, your OS is indeed sending WM_CHAR events, containing @ characters, straight into your Win32 application, whenever you press Ctrl+Alt+Q.
And like any other GUI application on Windows, this project should adhere to that by default too (except if a config setting is added later on obviously).
If the contents of WM_CHAR events don't prove anything to you then I'm pretty certain nothing will.

@lhecker commented on GitHub (May 13, 2020): > Do you have a reference for this claim? I doubt it. It's not a Windows thing, it's a Windows applications thing. And the instance that many applications do that (and actually do it wrong) does not make it better. "I doubt it."? Well I beg to differ! Both `Ctrl+Alt+Q` and `AltGr+Q` produce a character event containing "@" in Win32 and UWP applications. Feel free to test this yourself. I don't even know why I bothered to do so, but in fact I did write a demo application for you, so you don't have to: https://gist.github.com/lhecker/c437cf941531ce49f7e2b5706085dff3 You're making it painfully clear that you will absolutely not listen to anyone else's experience, so maybe the above <100 LOC will prove to you somehow, that... **Yes, your OS is indeed sending `WM_CHAR` events, containing @ characters, straight into your Win32 application, whenever you press Ctrl+Alt+Q.** And like any other GUI application on Windows, this project should adhere to that by default too (except if a config setting is added later on obviously). If the contents of `WM_CHAR` events don't prove anything to you then I'm pretty certain nothing will.

claunia commented

@lhecker commented on GitHub (May 13, 2020):

Here are your authoritative sources for Wikipedia by the way:

https://devblogs.microsoft.com/oldnewthing/20040329-00/?p=40003

The combination Ctrl+Alt is also known as AltGr [...]
For example, to type the @ character on a German keyboard, you would type AltGr+Q = Ctrl+Alt+Q.
https://docs.microsoft.com/en-us/windows/win32/uxguide/inter-keyboard

Don't use Ctrl+Alt combinations, because Windows interprets this combination in some language versions as an AltGR key, which generates alphanumeric characters.
https://docs.microsoft.com/en-us/previous-versions/windows/desktop/dnacc/guidelines-for-keyboard-user-interface-design

Avoid CTRL+ALT combinations because the system interprets this combination in some language versions as an ALTGR key, which generates alphanumeric characters.
https://docs.microsoft.com/en-us/windows/console/console-virtual-terminal-sequences

Left Ctrl + Right Alt is treated as AltGr.
https://docs.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/user-interface/keyboard-shortcuts-controls

Don't choose any key combination that involves Ctrl+Alt, because this combination maps to Alt+Gr for some Eastern European languages and will conflict with other shortcuts.

I'm certain actual OS sources won't be posted.
As such I kindly suggest reverting your Wikipedia changes soonish.

I'd like to stress once again that a config setting for this would be most preferable, but - as usual - someone will have to open a PR for that.

@lhecker commented on GitHub (May 13, 2020): Here are your authoritative sources for Wikipedia by the way: * https://devblogs.microsoft.com/oldnewthing/20040329-00/?p=40003 > The combination Ctrl+Alt is also known as AltGr [...] > For example, to type the @ character on a German keyboard, you would type AltGr+Q = Ctrl+Alt+Q. * https://docs.microsoft.com/en-us/windows/win32/uxguide/inter-keyboard > Don't use Ctrl+Alt combinations, because Windows interprets this combination in some language versions as an AltGR key, which generates alphanumeric characters. * https://docs.microsoft.com/en-us/previous-versions/windows/desktop/dnacc/guidelines-for-keyboard-user-interface-design > Avoid CTRL+ALT combinations because the system interprets this combination in some language versions as an ALTGR key, which generates alphanumeric characters. * https://docs.microsoft.com/en-us/windows/console/console-virtual-terminal-sequences > Left Ctrl + Right Alt is treated as AltGr. * https://docs.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/user-interface/keyboard-shortcuts-controls > Don't choose any key combination that involves Ctrl+Alt, because this combination maps to Alt+Gr for some Eastern European languages and will conflict with other shortcuts. I'm certain actual OS sources won't be posted. As such I kindly suggest reverting your Wikipedia changes soonish. I'd like to stress once again that a config setting for this would be most preferable, but - as usual - someone will have to open a PR for that.

claunia commented

@mintty commented on GitHub (May 13, 2020):

... not listen to anyone else ...

Come on, this is nonsense. I was just asking for a specification rather than speculation by experience.
Also I've meanwhile debugged the ToUnicode function (an alternative to using WM_CHAR) to find the same. Thanks for the references. However:

And like any other GUI application on Windows, this project should adhere to that by default too (except if a config setting is added later on obviously).

This is still not a strict conclusion. A terminal is not like any other GUI application. I've outlined the difference above and explained the use case. If a terminal had the option to choose behaviour, I wouldn't mind the default value, but constant remapping of Ctrl+Alt so that this modifier combination is not usable is not a good idea.

@mintty commented on GitHub (May 13, 2020): > ... not listen to anyone else ... Come on, this is nonsense. I was just asking for a specification rather than speculation by experience. Also I've meanwhile debugged the ToUnicode function (an alternative to using WM_CHAR) to find the same. Thanks for the references. However: > And like any other GUI application on Windows, this project should adhere to that by default too (except if a config setting is added later on obviously). This is still not a strict conclusion. A terminal is not like any other GUI application. I've outlined the difference above and explained the use case. If a terminal had the option to choose behaviour, I wouldn't mind the default value, but constant remapping of Ctrl+Alt so that this modifier combination is not usable is not a good idea.

claunia commented

@lhecker commented on GitHub (May 13, 2020):

You edited Wikipedia (!!) within... 3 hours after the start of this discussion, despite it containing a very credible source for that claim (oldnewthing), further sources for this being easily discoverable using Google AND two people telling you about this fact. And on top of that you write in Talk:AltGr that you changed this "following a discussion", which couldn't ever be further from the truth.
I mean was it really necessary for you to debug ToUnicode before moving the goalposts?
Am I really the only one here that had - potentially has - a problem with such behavior?

Anyways, we now know that applications with keyboard input on Windows are officially supposed to treat Ctrl+Alt as a substitute for AltGr. We've thus established that the current behavior correctly matches the default behavior and thus isn't a bug.
But a terminal indeed isn't like any other GUI application and a config switch would be nice.
Since that would be a new feature, may I ask you to please create a separate issue for this?

@lhecker commented on GitHub (May 13, 2020): _You edited Wikipedia_ (!!) within... 3 hours after the start of this discussion, despite it containing a very credible source for that claim (oldnewthing), further sources for this being easily discoverable using Google AND two people telling you about this fact. And on top of that you write in [Talk:AltGr](https://en.wikipedia.org/wiki/Talk:AltGr_key#Ctrl-Alt_or_AltGr) that you changed this "following a discussion", which couldn't ever be further from the truth. I mean was it really necessary for you to debug `ToUnicode` before moving the goalposts? Am I _really_ the only one here that had - potentially has - a problem with such behavior? Anyways, we now know that applications with keyboard input on Windows are officially supposed to treat Ctrl+Alt as a substitute for AltGr. We've thus established that the current behavior correctly matches the default behavior and thus isn't a bug. But a terminal indeed isn't like any other GUI application and a config switch would be nice. Since that would be a new feature, may I ask you to please create a separate issue for this?

claunia commented

@mintty commented on GitHub (May 13, 2020):

Let's not run a fruitless blame war here. The few words I changed on Wikipedia were not wrong, and the inclusion of references (which were missing for the original claim) is a Wikipedia policy. I've meanwhile tuned the words again.
You checked about WM_CHAR, I checked about ToUnicode, I don't see what problem you see there.

And yet, your interpretation of the references ("applications ... are officially supposed...") is biased: For example,

the system interprets this combination in some language versions as an ALTGR key

means it's the system default, not a requirement for applications to follow this behaviour.
We can agree that the simplified behaviour is not a bug in the Windows world but I'd still say it's a bad choice for a terminal application. So yes, someone should raise an issue.

@mintty commented on GitHub (May 13, 2020): Let's not run a fruitless blame war here. The few words I changed on Wikipedia were not wrong, and the inclusion of references (which were missing for the original claim) is a Wikipedia policy. I've meanwhile tuned the words again. You checked about WM_CHAR, I checked about ToUnicode, I don't see what problem you see there. And yet, your interpretation of the references ("applications ... are officially supposed...") is biased: For example, > the system interprets this combination in some language versions as an ALTGR key means it's the system default, not a requirement for applications to follow this behaviour. We can agree that the simplified behaviour is not a bug in the Windows world but I'd still say it's a bad choice for a terminal application. So yes, someone should raise an issue.

claunia commented

@mintty commented on GitHub (May 13, 2020):

Forgot to mention that actually one of your references supports my interpretation, regardless of actual Windows behaviour, it explicitly points out Right Alt:

Left Ctrl + Right Alt is treated as AltGr.

@mintty commented on GitHub (May 13, 2020): Forgot to mention that actually one of your references supports my interpretation, regardless of actual Windows behaviour, it explicitly points out **Right** Alt: > Left Ctrl + Right Alt is treated as AltGr.

claunia commented

@vuori commented on GitHub (May 19, 2020):

Ctrl+Alt combinations are used a lot in Emacs, so having only Ctrl + Right Alt be AltGr would be very beneficial for tty Emacs. It seems like there won't be consensus on a single default, so would there be interest if I looked into adding a configuration option for this?

@vuori commented on GitHub (May 19, 2020): Ctrl+Alt combinations are used a lot in Emacs, so having only Ctrl + **Right** Alt be AltGr would be very beneficial for tty Emacs. It seems like there won't be consensus on a single default, so would there be interest if I looked into adding a configuration option for this?

claunia commented

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

FYI If you want to tackle this...
The current logic is: If CtrlAlt is held and a /[ A-Z]/ (ASCII: 0x20,0x41-0x5A) character is pressed it'll generate a ^[^<letter> sequence.
Now the problem is that Windows treats any CtrlAlt as an alias for AltGr and some people like pressing CtrlAlt< for | which shouldn't be turned into the above sequence. Currently this decision is made based on whether the pressed character (here: <) fits in the above range (which it doesn't).

Now that I finished writing this I realize that @ (0x40) should actually be included in that range. 🤔
This is the code the way it used to be when this project got open-sourced and... as far as I can see... the current code is at least functionally equivalent right? If I'm correct we don't have any regressions at least and we can tackle a new feature: Toggling Ctrl-Alt <> AltGr aliasing.

The decision code is here: c78f264b4b/src/terminal/input/terminalInput.cpp (L495-L518)

Implementing this isn't quite trivial I believe, because TerminalInput is being called twice as far as I understand the inner workings of this project: Once on the sending side (basically the terminal) and once on the receiving side (in front of the shell). You need to implement a config setter to TerminalInput and keep the config state in sync between the two processes.

@lhecker commented on GitHub (May 19, 2020): FYI If you want to tackle this... The current logic is: If <kbd>Ctrl</kbd><kbd>Alt</kbd> is held **and** a `/[ A-Z]/` (ASCII: `0x20,0x41-0x5A`) character is pressed it'll generate a `^[^<letter>` sequence. Now the problem is that Windows treats any <kbd>Ctrl</kbd><kbd>Alt</kbd> as an alias for <kbd>AltGr</kbd> and some people like pressing <kbd>Ctrl</kbd><kbd>Alt</kbd><kbd>\<</kbd> for `|` which shouldn't be turned into the above sequence. Currently this decision is made based on whether the pressed character (here: `<`) fits in the above range (which it doesn't). Now that I finished writing this I realize that `@` (`0x40`) should actually be included in that range. :thinking: [This is the code](https://github.com/microsoft/terminal/blob/5de9fa9cf375e9b5bdc582d8d166604eeb519844/src/terminal/input/terminalInput.cpp#L482-L483) the way it used to be when this project got open-sourced and... _as far as I can see..._ the current code is at least functionally equivalent right? If I'm correct we don't have any regressions at least and we can tackle a new feature: Toggling Ctrl-Alt <> AltGr aliasing. The decision code is here: https://github.com/microsoft/terminal/blob/c78f264b4b64b58589d4cb34697aaf4e18499266/src/terminal/input/terminalInput.cpp#L495-L518 Implementing this isn't quite trivial I believe, because `TerminalInput` is being called twice as far as I understand the inner workings of this project: Once on the sending side (basically the terminal) and once on the receiving side (in front of the shell). You need to implement a config setter to `TerminalInput` and keep the config state in sync between the two processes.

claunia commented

@mintty commented on GitHub (May 19, 2020):

@vuori, thanks for offering this.

Implementing this isn't quite trivial I believe, ...

If you hook into the WM_KEYDOWN event, confining AltGr to Ctrl+right-Alt is not too difficult. You can modify the keyboard state before further interpretation with either TranslateMessage/WM_CHAR or ToUnicode (which seem to be the 2 options I see).
It is even possible to support distinct AltGr and Ctrl+right-Alt because for AltGr, Windows sends the Ctrl and right-Alt events with the same timestamp. Mintty makes that distinction.
However, not all keyboard event providers (such as on-screen keyboard and some remote desktop tools) do not follow the Windows usage of right-Alt with the same timestamp; mintty contains a few workarounds to do the best for those buggy tools as well, which is a bit tricky...

@mintty commented on GitHub (May 19, 2020): @vuori, thanks for offering this. > Implementing this isn't quite trivial I believe, ... If you hook into the WM_KEYDOWN event, confining AltGr to Ctrl+right-Alt is not too difficult. You can modify the keyboard state before further interpretation with either TranslateMessage/WM_CHAR or ToUnicode (which seem to be the 2 options I see). It is even possible to support distinct AltGr and Ctrl+right-Alt because for AltGr, Windows sends the Ctrl and right-Alt events with the same timestamp. Mintty makes that distinction. However, not all keyboard event providers (such as on-screen keyboard and some remote desktop tools) do not follow the Windows usage of right-Alt with the same timestamp; mintty contains a few workarounds to do the best for those buggy tools as well, which is a bit tricky...

claunia commented

@lhecker commented on GitHub (May 26, 2020):

@mintty I'm sorry for having been that harsh to you last week. I'm still slightly angered about the Wikipedia situation, but I fully realize I wasn't quite fair either.
To make up for this I've decided to go ahead and add a altGrAliasing setting to this project: #6211 / #6212

@lhecker commented on GitHub (May 26, 2020): @mintty I'm sorry for having been that harsh to you last week. I'm still slightly angered about the Wikipedia situation, but I fully realize I wasn't quite fair either. To make up for this I've decided to go ahead and add a `altGrAliasing` setting to this project: #6211 / #6212

claunia commented

@mintty commented on GitHub (May 27, 2020):

@lhecker, thanks for the initiative. As a representative of a competitor application, it would have looked weird if I had raised an issue for it:)

@mintty commented on GitHub (May 27, 2020): @lhecker, thanks for the initiative. As a representative of a competitor application, it would have looked weird if I had raised an issue for it:)

claunia commented