Autohotkey AltGr+7, AltGr+8, AltGr+9, and AltGr+0 reassignments lost in Windows Terminal Preview and Windows Terminal

[svivar]

Environment

Windows build number: [run `[Environment]::OSVersion` for powershell, or `ver` for cmd]
Windows Terminal version (if applicable):

Any other software?

Microsoft Windows [Version 10.0.19042.388]

Steps to reproduce

Expected behavior

I use the Spanish (ES) keyboard configuration and I have an autohotkey script that reassigns AltGr+, (comma), AltGr+. (period), AltGr+7, AltGr+8, AltGr+9, and AltGr+0 to <, >, «, », ‹, and ›, respectively.

I installed Windows Terminal and these keys-to-output reassignments worked great in tabs running PowerShell, cmd, Debian, and Ubuntu.

Actual behavior

I subsequently installed Windows Terminal Preview and found that AltGr+7, AltGr+8, AltGr+9, and AltGr+0 no longer produced any output. But the reassignment of outputs of AltGr+, (comma) and AltGr+. (period) to < and >, respectively, remain functional.

Windows Terminal also began exhibiting the same behavior.

The 6 autohotkey keys-to-output reassignments continue to work for all other applications.

[zadjii-msft]

You know what, I bet I busted this up when I was doing #4999. Summoning @lhecker for debugging advice ☺️

[lhecker]

This can be tested by adding a keyboard layout that has an AltGr key (Spanish, German, French, ...) and running the following AutoHotKey script:

#NoEnv ; Recommended for performance and compatibility with future AutoHotkey releases.
#Warn ; Enable warnings to assist with detecting common errors.
SendMode Input ; Recommended for new scripts due to its superior speed and reliability.
SetWorkingDir %A_ScriptDir% ; Ensures a consistent starting directory.

<^>!,::SendInput {Raw}<
<^>!.::SendInput {Raw}>
<^>!7::SendInput {Raw}«
<^>!8::SendInput {Raw}»
<^>!9::SendInput {Raw}‹
<^>!0::SendInput {Raw}›

---

AFAICS the underlying issue is that #4999 breaks international character inputs, by handling all key events, thereby suppressing follow up character events. Key events are based on ASCII, making them fundamentally unsuitable to accurately recreate character inputs purely based on key event data. Our prior logic ignored all key events for which ToUnicodeEx returned a valid character and those who aren't in the special key-combination list in terminalInput.cpp.

AutoHotKey uses SendInput(). Using a German keyboard layout SendInput() first generates a Fn-key sequence (vkey = 255, scan_code = 0, ch = 0). WT (since #4999) acknowledges this sequence and thus prevents the unicode character (e.g. "»") from ever being sent to the character event handler.

---

For the time being I suggest non-US Terminal users to set "experimental.input.forceVT": true in their config.

[lhecker]

I've opened a PR with an idea how I think this issue can be solved. 🙂 #7145

[svivar]

Thank you, @lhecker and @zadjii-msft . This comment may seem to be a digression to autohotkey, but I am posting it in case it's relevant to testing the fix to microsoft terminal preview. This is my autohotkey script:

<^>!,::Send <
<^>!.::Send >
<^>!7::Send {U+00AB}
<^>!8::Send {U+00BB}
<^>!9::Send {U+2039}
<^>!0::Send {U+203A}

Pressing those key sequences produces <>«»‹› in Notepad.

When I run the autohotkey script from @lhecker, these are what appear in Notepad: <>«»‹›

#NoEnv ; Recommended for performance and compatibility with future AutoHotkey releases.
#Warn ; Enable warnings to assist with detecting common errors.
SendMode Input ; Recommended for new scripts due to its superior speed and reliability.
SetWorkingDir %A_ScriptDir% ; Ensures a consistent starting directory.
<^>!,::SendInput {Raw}<
<^>!.::SendInput {Raw}>
<^>!7::SendInput {Raw}«
<^>!8::SendInput {Raw}»
<^>!9::SendInput {Raw}‹
<^>!0::SendInput {Raw}›

I am currently running AutoHotkey 1.1.33.02.

[ghost]

🎉This issue was addressed in #7145, which has now been successfully released as Windows Terminal Preview v1.2.2234.0.:tada:

Handy links:

• Release Notes
• Store Download