Ctrl+Alt+'char' generates other chars then 'AltGr' (Germany Layout) v0.11.1121.0

[Ztarbox]

Environment

Windows build number: Microsoft Windows NT 10.0.19041.0
Windows Terminal version (if applicable): v0.11.1121.0

Steps to reproduce

In german keyboard layout type Ctrl+Alt+< (or any other key that has a 3rd char on it).

Expected behavior

Shows the same as AltGr+<
the pipe char: |

Actual behavior

Shows the # hash sign.

Additional remarks

This started on v0.11 till the fixing of AltGr months ago, this didn't happen till today.
On german keyboard layout at least, AltGr+key and Ctrl+Alt+key always return the same char.

some other examples on pwsh:

Key	AltGr	Ctrl+Alt
<	Pipe	#
q	@	"
e	€	€
7	{	^[
8	[	^[
9	]	+
+	~	&

cmd in terminal returns also different chars but other (mostly ^] or ^\)
wsl doesn't support Ctrl+Alt at all, but I don't need it there and I'm not sure, if it worked there till v0.11,

I mostly recognized this problem while typing PowerShell, cause its way faster to create the | (pipe) using Ctrl+Alt+< on the left side of the keyboard then AltGr+< cause this would require two hands.

[zadjii-msft]

Congratulations, since you posted the thread first, you get to be the tracking thread for this issue.

@lhecker (our resident person who owns a non-en-us keyboard) for visibility.

---

From other threads:
@Alxandr in #5530

Environment

Windows build number: 
Platform ServicePack Version      VersionString
-------- ----------- -------      -------------
 Win32NT             10.0.18363.0 Microsoft Windows NT 10.0.18363.0

Windows Terminal version (if applicable):
0.11.200421001-release0.11

Any other software?

Steps to reproduce

Use a Norwegian keyboard layout, and attempt to use @ (altgr+2), $ (altgr+4) or { (altgr+7), or others in terminal.

Expected behavior

The keys should show up in the terminal, just like they would in the old windows console host or any code editor.

Actual behavior

Depending on how many tabs you have open in the terminal, multiple things can happen. If you only have 1 tab open, @ (altgr+2) and $ (altgr+4) works. If you have 2 tabs open, @ stops working and instead goes to the second tab. If you have 4 or more tabs, $ stops working and goes to the fourth tab. { never works as expected and inserts ^[ (which is a really unfortunate escape code) if you have fewer than 7 tabs, and (as would be expected at this point) navigates you to the seventh tab if you have that many.

All of this can be seen in the gif below (note that Carnac also displays the keys pressed as US keyboard layout, so instead of = (shift+0) it displays )):

Having altgr+# as a keyboard shortcut by default in any program intended for developers is likely going to break for a large number of users who do not use US keyboard layout, as that is generally where the programming symbols are. All of the following are behind altgr+# on Norwegian keyboards for instance: @${[]}.

[lhecker]

Sorry for that. This issue is caused by me removing this particular character range check in #4192:

terminal/src/terminal/input/terminalInput.cpp

Lines 482 to 483 in 5de9fa9

	((keyEvent.GetVirtualKeyCode() > 0x40 && keyEvent.GetVirtualKeyCode() <= 0x5A) ||
	keyEvent.GetVirtualKeyCode() == VK_SPACE))

@zadjii-msft I'd gladly submit a PR which re-adds the vkey range check.

---

In all these years I honestly personally never used CtrlAlt as a replacement for AltGr, which is why I didn't check this at all. 😞
And I removed the check, as it seemed kinda "fiddly" (?). I thought to myself:

What if there are virtual keys outside that range which map to characters that are entirely valid? And in general AltGr combinations are detected by testing for Right-Alt in this project anyways only.

[zadjii-msft]

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

[ghost]

🎉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
• Store Download

[mintty]

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.

[Ztarbox]

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?

[lhecker]

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

@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. ¯\_(ツ)_/¯ 🙂

[mintty]

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.

[Ztarbox]

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

[mintty]

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.

[lhecker]

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]

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.

[mintty]

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

[lhecker]

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?

[mintty]

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]

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.

[vuori]

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?

[lhecker]

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:

terminal/src/terminal/input/terminalInput.cpp

Lines 495 to 518 in c78f264

	if (keyEvent.IsAltPressed() && keyEvent.IsCtrlPressed())
	{
	auto ch = keyEvent.GetCharData();
	if (ch == UNICODE_NULL)
	{
	// For Alt+Ctrl+Key messages GetCharData() returns 0.
	// The values of the ASCII characters and virtual key codes
	// of <Space>, A-Z (as used below) are numerically identical.
	// -> Get the char from the virtual key.
	ch = keyEvent.GetVirtualKeyCode();
	}
	// Alt+Ctrl acts as a substitute for AltGr on Windows.
	// For instance using a German keyboard both AltGr+< and Alt+Ctrl+< produce a | (pipe) character.
	// The below condition primitively ensures that we allow all common Alt+Ctrl combinations
	// while preserving most of the functionality of Alt+Ctrl as a substitute for AltGr.
	if (ch == UNICODE_SPACE || (ch > 0x40 && ch <= 0x5A))
	{
	// Pressing the control key causes all bits but the 5 least
	// significant ones to be zeroed out (when using ASCII).
	ch &= 0b11111;
	_SendEscapedInputSequence(ch);
	return true;
	}
	}

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.

[mintty]

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

[lhecker]

@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

[mintty]

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

[DHowett]

@mintty We have a couple “competitors” hanging out around here! I love that we can all come together as a community to give our users the best experience possible. 😄

@lhecker, thanks for taking the initiative on this. It means a lot to me!