-
Notifications
You must be signed in to change notification settings - Fork 8.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Autohotkey AltGr+7, AltGr+8, AltGr+9, and AltGr+0 reassignments lost in Windows Terminal Preview and Windows Terminal #7064
Comments
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 AutoHotKey uses For the time being I suggest non-US Terminal users to set |
I've opened a PR with an idea how I think this issue can be solved. 🙂 #7145 |
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:
Pressing those key sequences produces <>«»‹› in Notepad. When I run the autohotkey script from @lhecker, these are what appear in Notepad: <>«»‹›
I am currently running AutoHotkey 1.1.33.02. |
Up until #4999 we deferred all key events to the character event handler for which `ToUnicodeEx` returned a valid character and alternatively those who aren't a special key combination as listed in `TerminalInput`'s implementation. Since #4999 we started acknowledging/handling all key events no matter whether they're actually a known key combination. Given non-ASCII inputs the Win32 `SendInput()` method generates certain sequences that aren't recognizable combinations though and if they're handled by the key event handler no follow up character event is sent containing the unicode character. This PR adds another condition and defers all key events without scan code (i.e. those not representable by the current keyboard layout) to the character event handler. I'm absolutely not certain that this PR doesn't have a negative effect on other kinds of inputs. Is it common for key events to not contain a scan code? I personally haven't seen it happen before AutoHotKey/SendInput. Before this PR is merged it'd be nice to have a good testing plan in place in order to ensure nothing breaks. ## Validation Steps Performed Remapped `AltGr+8` to `»` using AutoHotKey using `<^>!8::SendInput {Raw}»`. Ensured `»` is printed if `AltGr+8` is pressed. Closes #7064 Closes #7120
Up until #4999 we deferred all key events to the character event handler for which `ToUnicodeEx` returned a valid character and alternatively those who aren't a special key combination as listed in `TerminalInput`'s implementation. Since #4999 we started acknowledging/handling all key events no matter whether they're actually a known key combination. Given non-ASCII inputs the Win32 `SendInput()` method generates certain sequences that aren't recognizable combinations though and if they're handled by the key event handler no follow up character event is sent containing the unicode character. This PR adds another condition and defers all key events without scan code (i.e. those not representable by the current keyboard layout) to the character event handler. I'm absolutely not certain that this PR doesn't have a negative effect on other kinds of inputs. Is it common for key events to not contain a scan code? I personally haven't seen it happen before AutoHotKey/SendInput. Before this PR is merged it'd be nice to have a good testing plan in place in order to ensure nothing breaks. ## Validation Steps Performed Remapped `AltGr+8` to `»` using AutoHotKey using `<^>!8::SendInput {Raw}»`. Ensured `»` is printed if `AltGr+8` is pressed. Closes #7064 Closes #7120 (cherry picked from commit b617c43)
🎉This issue was addressed in #7145, which has now been successfully released as Handy links: |
…virtual keycode and a scan code of 0 (#15753) ## Summary Applications like PowerToys, with their keyboard remapping features frequently (i.e whenever a remapped shortcut is triggerred) send `KeyEvent` with out-of-range virtual keycode values (E.g. 0xFF). This is fixed for WT in #7145, we just needed it in our good ol' `conhost`. After this PR, Key events with an invalid virtual keycode and scancode==0 are ignored, and are not added to the `InputBuffer`. Incase, only virtual keycode is valid but not scancode, we will try to infer the correct scancode using the virtual keycode mapping. ## References and Relevant Issues #7145 #7064 ## Validation Steps Performed - Triggered a remapped shortcut and verified that `showkey -a` doesn't output `^@` unexpectedly. - Key events with an Invalid virtual Keycode and Scancode == 0 are ignored. - This PR doesn't include any changes for `WM_[SYS][DEAD]CHAR` messages, they are left unchanged.
Environment
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.
The text was updated successfully, but these errors were encountered: