Skip to content

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

New issue
New issue
Closed
#7145
Closed
Autohotkey AltGr+7, AltGr+8, AltGr+9, and AltGr+0 reassignments lost in Windows Terminal Preview and Windows Terminal#7064
#7145
Labels
Area-InputRelated to input processing (key presses, mouse, etc.)Help WantedWe encourage anyone to jump in on these.Issue-BugIt either shouldn't be doing this or needs an investigation.Priority-2A description (P2)Product-TerminalThe new Windows Terminal.Resolution-Fix-CommittedFix is checked in, but it might be 3-4 weeks until a release.
Milestone
Terminal v2.0

Description

@svivar
svivar
opened on Jul 24, 2020

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.

Activity

  1. ghost added
    Needs-TriageIt's a new issue that the core contributor team needs to triage at the next triage meeting
    on Jul 24, 2020
  2. ghost added
    Needs-Tag-FixDoesn't match tag requirements
    on Jul 24, 2020

  3. zadjii-msft commented on Jul 28, 2020

    @zadjii-msft
    Mike Griese (zadjii-msft)
    on Jul 28, 2020
    Member

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

  4. Mike Griese (zadjii-msft)
    added
    Area-InputRelated to input processing (key presses, mouse, etc.)
    Issue-BugIt either shouldn't be doing this or needs an investigation.
    Priority-2A description (P2)
    Product-TerminalThe new Windows Terminal.
    on Jul 28, 2020
  5. ghost removed
    Needs-Tag-FixDoesn't match tag requirements
    on Jul 28, 2020
  6. Dustin L. Howett (DHowett)
    added this to the Terminal v2.0 milestone on Jul 31, 2020
  7. Dustin L. Howett (DHowett)
    added
    Help WantedWe encourage anyone to jump in on these.
    and removed
    Needs-TriageIt's a new issue that the core contributor team needs to triage at the next triage meeting
    on Jul 31, 2020

  8. lhecker commented on Aug 1, 2020

    @lhecker
    Leonard Hecker (lhecker)
    on Aug 1, 2020
    Member

    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.

  9. ghost added
    In-PRThis issue has a related PR
    on Aug 1, 2020

  10. lhecker commented on Aug 1, 2020

    @lhecker
    Leonard Hecker (lhecker)
    on Aug 1, 2020
    Member

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

  11. svivar commented on Aug 1, 2020

    @svivar
    svivar
    on Aug 1, 2020
    Author

    Thank you, Leonard Hecker (@lhecker) and Mike Griese (@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 Leonard Hecker (@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.

  12. ghost closed this as completedin #7145on Aug 6, 2020
  13. ghost removed
    In-PRThis issue has a related PR
    on Aug 6, 2020
  14. ghost added a commit that references this issue on Aug 6, 2020

    Fix #7064: Ignore key events without scan code (#7145)

    b617c43
  15. ghost added
    Resolution-Fix-CommittedFix is checked in, but it might be 3-4 weeks until a release.
    on Aug 6, 2020
  16. Dustin L. Howett (DHowett)
    added a commit that references this issue on Aug 11, 2020

    Fix #7064: Ignore key events without scan code (#7145)

    5d74557
  18. Mike Griese (zadjii-msft)
    added a commit that references this issue on Aug 8, 2023

    ConHost: Ignore WM_[SYS]KEYDOWN/WM_[SYS]KEYUP events with an invalid …

    9b70a40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Area-InputRelated to input processing (key presses, mouse, etc.)Help WantedWe encourage anyone to jump in on these.Issue-BugIt either shouldn't be doing this or needs an investigation.Priority-2A description (P2)Product-TerminalThe new Windows Terminal.Resolution-Fix-CommittedFix is checked in, but it might be 3-4 weeks until a release.

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions