starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

TerminalControl handles ALT+NUMPAD input poorly #1872

New Issue
Closed
opened 2026-01-30 22:40:38 +00:00 by claunia · 17 comments
claunia commented 2026-01-30 22:40:38 +00:00
Owner
Copy Link

Originally created by @leoniDEV on GitHub (Jun 22, 2019).

Originally assigned to: @leonMSFT on GitHub.

When the user enters Alt-123 it looks like we're doing this:

  • Sending ESC 1
  • Sending 2
  • Sending 3
  • Sending whichever character Alt-123 corresponds to.

Powershell and bash (readline) interpret alt-number as "enter digit-argument mode." Digit argument mode usually means "repeat the first character N times" ... so this results in character 123 being added to the buffer 123 times.

We should definitely fix that.

original content

Environment

Windows build number: 10.0.18922.1000 and 10.0.18362.175
Windows Terminal version (if applicable): 0.2.1715.0

Any other software?
Powershell Core 7.0.0-preview.1
Powershell Core 6.2.1
Windows Powershell 5.1

Steps to reproduce

  • Open Powershell (whatever version listed above) session in the Terminal
  • try to insert an ascii char by:
    • press and hold ALT key
    • digit whatever number (for example 126 corresponding to ~)

Expected behavior

a tilde (~) is inserted
WinTerPS7ok

Actual behavior

127 tildes are inserted
WinTerPS7

The same thing happens for all the versions of Powershell listed above

Originally created by @leoniDEV on GitHub (Jun 22, 2019). Originally assigned to: @leonMSFT on GitHub. When the user enters <kbd>Alt-123</kbd> it looks like we're doing this: * Sending `ESC` `1` * Sending `2` * Sending `3` * Sending whichever character <kbd>Alt-123</kbd> corresponds to. Powershell and bash (readline) interpret alt-number as "enter digit-argument mode." Digit argument mode usually means "repeat the first character N times" ... so this results in character `123` being added to the buffer 123 times. We should definitely fix that. # original content ## Environment ``` Windows build number: 10.0.18922.1000 and 10.0.18362.175 Windows Terminal version (if applicable): 0.2.1715.0 Any other software? Powershell Core 7.0.0-preview.1 Powershell Core 6.2.1 Windows Powershell 5.1 ``` ## Steps to reproduce - Open Powershell (whatever version listed above) session in the Terminal - try to insert an ascii char by: - press and hold `ALT` key - digit whatever number (for example 126 corresponding to `~`) ## Expected behavior a tilde (`~`) is inserted ![WinTerPS7ok](https://user-images.githubusercontent.com/11667486/59962852-317cd200-94eb-11e9-899c-bbdbd70087e5.png) ## Actual behavior 127 tildes are inserted ![WinTerPS7](https://user-images.githubusercontent.com/11667486/59962859-43f70b80-94eb-11e9-9f20-83f6d0938434.png) <!-- What's actually happening? --> The same thing happens for all the versions of Powershell listed above
claunia commented 2026-01-30 22:40:39 +00:00
Author
Owner
Copy Link

@Shorotshishir commented on GitHub (Jun 25, 2019):

Weird behavior in all terminals: Numpad on/off state changes the output

  • WSL is making multiples of the corresponding ASCII character while Numpad is active (i.e. num lock on) ↓↓

wsl alt+5

  • CMD is making adding the number corresponding ASCII character while Numpad is active (i.e. num lock on) ↓↓

cmd alt+5

  • PowerShell is making multiples of the corresponding ASCII character while Numpad is active (i.e. num lock on) character won't show. ↓↓

powershell alt+5

@Shorotshishir commented on GitHub (Jun 25, 2019): Weird behavior in all terminals: Numpad on/off state changes the output - **WSL** is making multiples of the corresponding ASCII character while Numpad is active (i.e. num lock on) ↓↓ ![wsl alt+5](https://user-images.githubusercontent.com/16465879/60068056-f23ec300-972e-11e9-8842-9c23344346bc.png) - **CMD** is making adding the number corresponding ASCII character while Numpad is active (i.e. num lock on) ↓↓ ![cmd alt+5](https://user-images.githubusercontent.com/16465879/60068057-f23ec300-972e-11e9-8821-5f38377e7753.png) - **PowerShell** is making multiples of the corresponding ASCII character while Numpad is active (i.e. num lock on) character won't show. ↓↓ ![powershell alt+5](https://user-images.githubusercontent.com/16465879/60068060-f2d75980-972e-11e9-848b-c103d08bd8c1.png)
claunia commented 2026-01-30 22:40:40 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Jun 26, 2019):

When the user enters Alt-123 it looks like we're doing this:

  • Sending ESC 1
  • Sending 2
  • Sending 3
  • Sending whichever character Alt-123 corresponds to.

Powershell and bash (readline) interpret alt-number as "enter digit-argument mode." Digit argument mode usually means "repeat the first character N times" ... so this results in character 123 being added to the buffer 123 times.

We should definitely fix that.

@DHowett-MSFT commented on GitHub (Jun 26, 2019): When the user enters <kbd>Alt-123</kbd> it looks like we're doing this: * Sending `ESC` `1` * Sending `2` * Sending `3` * Sending whichever character <kbd>Alt-123</kbd> corresponds to. Powershell and bash (readline) interpret alt-number as "enter digit-argument mode." Digit argument mode usually means "repeat the first character N times" ... so this results in character `123` being added to the buffer 123 times. We should definitely fix that.
claunia commented 2026-01-30 22:40:40 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Jun 26, 2019):

If someone (potentially inexperienced with this project) wants to debug this issue they might find the following line of interest:
5dd1f8d38a/src/terminal/input/terminalInput.cpp (L428)

It's the one responsible for generating the escape codes.

The following callback then sends these further to the shell:
5dd1f8d38a/src/cascadia/TerminalCore/Terminal.cpp (L53-L60)

(_pfnWriteInput goes straight to TermControl::_SendInputToConnection in our case which is then the last stage before the shell I suppose).
If you hold Alt and enter 64 on the Numpad it will then generate the following input sequence for the shell: \x1b6\x1b4@ (\x1b being the escape character).

I'm personally not entirely certain where the @ is coming from, but I suspect this is generated by the Operating System and sent as a WM_CHAR message to the application here:
5dd1f8d38a/src/cascadia/TerminalControl/TermControl.cpp (L564-L565)

If I'm correct, then to go fully UNIXy we might want to prevent the OS from translating Alt+Numpad for us (however one would do that). Otherwise we should disable the call to _SendEscapedInputSequence I guess.

@lhecker commented on GitHub (Jun 26, 2019): If someone (potentially inexperienced with this project) wants to debug this issue they might find the following line of interest: https://github.com/microsoft/terminal/blob/5dd1f8d38ab584314c682afacbefaccb6478d67c/src/terminal/input/terminalInput.cpp#L428 It's the one responsible for generating the escape codes. The following callback then sends these further to the shell: https://github.com/microsoft/terminal/blob/5dd1f8d38ab584314c682afacbefaccb6478d67c/src/cascadia/TerminalCore/Terminal.cpp#L53-L60 (`_pfnWriteInput` goes straight to `TermControl::_SendInputToConnection` in our case which is then the last stage before the shell I suppose). If you hold `Alt` and enter 64 on the Numpad it will then generate the following input sequence for the shell: `\x1b6\x1b4@` (`\x1b` being the escape character). I'm personally not entirely certain where the @ is coming from, but I suspect this is generated by the Operating System and sent as a WM_CHAR message to the application here: https://github.com/microsoft/terminal/blob/5dd1f8d38ab584314c682afacbefaccb6478d67c/src/cascadia/TerminalControl/TermControl.cpp#L564-L565 If I'm correct, then to go fully UNIXy we might want to prevent the OS from translating Alt+Numpad for us (however one would do that). Otherwise we should disable the call to `_SendEscapedInputSequence` I guess.
claunia commented 2026-01-30 22:40:40 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Mar 20, 2020):

:tada:This issue was addressed in #4965, which has now been successfully released as Windows Terminal Preview v0.10.781.0.🎉

Handy links:

@ghost commented on GitHub (Mar 20, 2020): :tada:This issue was addressed in #4965, which has now been successfully released as `Windows Terminal Preview v0.10.781.0`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v0.10.781.0) * [Store Download](https://www.microsoft.com/store/apps/9n0dx20hk701?cid=storebadge&ocid=badge)
claunia commented 2026-01-30 22:40:40 +00:00
Author
Owner
Copy Link

@ilqvya commented on GitHub (Apr 10, 2020):

Still reproduces:
image

@ilqvya commented on GitHub (Apr 10, 2020): Still reproduces: ![image](https://user-images.githubusercontent.com/15274763/78996942-53b11080-7b4e-11ea-9d19-b7080d3dea89.png)
claunia commented 2026-01-30 22:40:40 +00:00
Author
Owner
Copy Link

@ilqvya commented on GitHub (Apr 10, 2020):

bug

@ilqvya commented on GitHub (Apr 10, 2020): ![bug](https://user-images.githubusercontent.com/15274763/78997186-b9050180-7b4e-11ea-88f8-13ec07f96e27.gif)
claunia commented 2026-01-30 22:40:41 +00:00
Author
Owner
Copy Link

@ilqvya commented on GitHub (Apr 10, 2020):

plz, reopen @avdi @shanselman @timheuer @alecthegeek @atifaziz @leonMSFT @leoniDev

@ilqvya commented on GitHub (Apr 10, 2020): plz, reopen @avdi @shanselman @timheuer @alecthegeek @atifaziz @leonMSFT @leoniDev
claunia commented 2026-01-30 22:40:41 +00:00
Author
Owner
Copy Link

@leonMSFT commented on GitHub (Apr 10, 2020):

Sorry about it still happening @effolkronium! From your repro, it almost looks like your Terminal never got the PR that fixed the thing where digit-argument starts #4965. I tried to repro this on a bunch of my machines. A couple of them are running a version of Terminal that's further ahead, but I have a couple that are also running 0.10.781.0, and it's working fine for me (so that's a real head scratcher). 😢 I'm also asking the rest of the team to see if they can repro what you're seeing, and so far no luck, I can't get a reliable repro for what you're seeing. For now the only thing I can suggest is I'd like for you to try reinstalling Terminal if you get a chance (this is a wild guess that may or may not work).

@leonMSFT commented on GitHub (Apr 10, 2020): Sorry about it still happening @effolkronium! From your repro, it almost looks like your Terminal never got the PR that fixed the thing where digit-argument starts #4965. I tried to repro this on a bunch of my machines. A couple of them are running a version of Terminal that's further ahead, but I have a couple that are also running 0.10.781.0, and it's working fine for me (so that's a real head scratcher). 😢 I'm also asking the rest of the team to see if they can repro what you're seeing, and so far no luck, I can't get a reliable repro for what you're seeing. For now the only thing I can suggest is I'd like for you to try reinstalling Terminal if you get a chance (this is a wild guess that may or may not work).
claunia commented 2026-01-30 22:40:41 +00:00
Author
Owner
Copy Link

@ilqvya commented on GitHub (Apr 11, 2020):

@leonMSFT

I think ALT worked well day or week ago for me.

as i can see terminal got the update at the end of last month. So i think it was ok with this version some time

I just re -installed the Terminal but the bug still reproduces. ^(((

...

Also it doesn't work with update before current. Maybe some OS or third party app impact...

I'll try to investigate a bit, maybe even debug the terminal by myself

@ilqvya commented on GitHub (Apr 11, 2020): @leonMSFT I think ALT worked well day or week ago for me. as i can see terminal got the update at the end of last month. So i think it was ok with this version some time I just re -installed the Terminal but the bug still reproduces. ^((( ... Also it doesn't work with update before current. Maybe some OS or third party app impact... I'll try to investigate a bit, maybe even debug the terminal by myself
claunia commented 2026-01-30 22:40:41 +00:00
Author
Owner
Copy Link

@ilqvya commented on GitHub (Apr 11, 2020):

Hmm, seems it do not recognize alt at all (the breakpoint when i press alt and then number)

image

@ilqvya commented on GitHub (Apr 11, 2020): Hmm, seems it do not recognize alt at all (the breakpoint when i press alt and then number) ![image](https://user-images.githubusercontent.com/15274763/79033433-fac99280-7bb6-11ea-97d0-ed620dcf94f0.png)
claunia commented 2026-01-30 22:40:41 +00:00
Author
Owner
Copy Link

@ilqvya commented on GitHub (Apr 11, 2020):

Ok, so this is my VirtKey for number 2

image

The check for NumberPad0 - NumberPad9 fails. I think it's because i press numbers below F row. not numpad.

@ilqvya commented on GitHub (Apr 11, 2020): Ok, so this is my VirtKey for number 2 ![image](https://user-images.githubusercontent.com/15274763/79033578-e5089d00-7bb7-11ea-8f7b-a3ca93187264.png) The check for NumberPad0 - NumberPad9 fails. I think it's because i press numbers below F row. not numpad.
claunia commented 2026-01-30 22:40:42 +00:00
Author
Owner
Copy Link

@ilqvya commented on GitHub (Apr 11, 2020):

Well, ignoring VirtualKey::Number0 - VirtualKey::Number9 doesn't help

it passes check but tab switch still no happening.

@leonMSFT

could you suggest what i should debug or look to for fix ?

@ilqvya commented on GitHub (Apr 11, 2020): Well, ignoring VirtualKey::Number0 - VirtualKey::Number9 doesn't help it passes check but tab switch still no happening. @leonMSFT could you suggest what i should debug or look to for fix ?
claunia commented 2026-01-30 22:40:42 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Apr 11, 2020):

dude, Alt NUMPAD input only works if you use the number pad. The numbers below the F keys aren’t the number pad.

@DHowett-MSFT commented on GitHub (Apr 11, 2020): dude, Alt NUMPAD input _only works if you use the number pad_. The numbers below the F keys aren’t the number pad.
claunia commented 2026-01-30 22:40:42 +00:00
Author
Owner
Copy Link

@ilqvya commented on GitHub (Apr 11, 2020):

dude, Alt NUMPAD input only works if you use the number pad. The numbers below the F keys aren’t the number pad.

Man, it worked well all the time when I used this app in past. I have no numpud on my keyboard

@ilqvya commented on GitHub (Apr 11, 2020): > dude, Alt NUMPAD input _only works if you use the number pad_. The numbers below the F keys aren’t the number pad. Man, it worked well all the time when I used this app in past. I have no numpud on my keyboard
claunia commented 2026-01-30 22:40:42 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Apr 11, 2020):

Correct me if I'm wrong, but...

@effolkronium Unfortunately if that has ever worked it must've been a bug anyways. Entering Alt codes with regular number keys most definitely wasn't a feature. I'm not aware of Windows supporting Alt codes with regular number keys in the first place.
Even DEC's later terminals (which this project is replicating to a large extent) only supported composition using the numeric keypad.

Some keyboards with Fn keys support entering numeric keypad codes using the main keyboard.
On one keyboard I had pressing FnM was the same as pressing Numpad0.
If your keyboard doesn't support that either you'll unfortunately not be able to enter Alt codes.
Your only alternative is Win.. As I said above, entering Alt codes with regular number keys most likely is not something this project will support in the future, as Windows itself normally doesn't support that either.

@lhecker commented on GitHub (Apr 11, 2020): Correct me if I'm wrong, but... @effolkronium Unfortunately if that has ever worked it must've been a bug anyways. Entering [Alt codes](https://en.wikipedia.org/wiki/Alt_code) with regular number keys most definitely wasn't a feature. I'm not aware of Windows supporting Alt codes with regular number keys in the first place. Even DEC's later terminals (which this project is replicating to a large extent) only supported composition using the numeric keypad. Some keyboards with <kbd>Fn</kbd> keys support entering numeric keypad codes using the main keyboard. On one keyboard I had pressing <kbd>Fn</kbd><kbd>M</kbd> was the same as pressing <kbd>Numpad0</kbd>. If your keyboard doesn't support that either you'll unfortunately not be able to enter Alt codes. Your only alternative is <kbd>Win</kbd><kbd>.</kbd>. As I said above, entering Alt codes with regular number keys most likely is not something this project will support in the future, as Windows itself normally doesn't support that either.
claunia commented 2026-01-30 22:40:42 +00:00
Author
Owner
Copy Link

@ilqvya commented on GitHub (Apr 11, 2020):

oK, so it works if i press alt+ctr+num.

i think ticket should be closed

@ilqvya commented on GitHub (Apr 11, 2020): oK, so it works if i press alt+ctr+num. i think ticket should be closed
claunia commented 2026-01-30 22:40:43 +00:00
Author
Owner
Copy Link

@DHowett-MSFT commented on GitHub (Apr 11, 2020):

@lhecker thanks for the excellent write up
@effolkronium thanks for confirming that you found a solution :)

@DHowett-MSFT commented on GitHub (Apr 11, 2020): @lhecker thanks for the excellent write up @effolkronium thanks for confirming that you found a solution :)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Area-TerminalControl Help Wanted Issue-Bug Priority-2 Product-Terminal Resolution-Fix-Committed
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#1872
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?