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

Alt + numpad combination does not work anymore #21780

New Issue
Closed
opened 2026-01-31 07:54:42 +00:00 by claunia · 8 comments
claunia commented 2026-01-31 07:54:42 +00:00
Owner
Copy Link

Originally created by @raksati on GitHub (May 28, 2024).

Windows Terminal version

1.21.1272.0

Windows build number

10.0.22631.0

Other Software

wsl terminal, powershell, etc.

Steps to reproduce

Sequential numpad keys combinations with the ALT key pressed to insert special characters ( for example the most common ones such as { with ALT+123, ~ with ALT+126, or the tilde ~ with ALT+126, etc. ) do not work anymore.

The latest working version is Microsoft.WindowsTerminal.Preview 1.20.11215.0, the next current one (1.21.1272.0) broke this functionality.

Expected Behavior

On previous versions the combination works

raksati@wsl:$ showkey -a

Press any keys - Ctrl-D will terminate this program

` 96 0140 0x60

^D 4 0004 0x04
raksati@wsl:~$

Actual Behavior

nothing is detected:

raksati@wsl:$ showkey -a

Press any keys - Ctrl-D will terminate this program

^D 4 0004 0x04
raksati@wsl:~$

Originally created by @raksati on GitHub (May 28, 2024). ### Windows Terminal version 1.21.1272.0 ### Windows build number 10.0.22631.0 ### Other Software wsl terminal, powershell, etc. ### Steps to reproduce Sequential numpad keys combinations with the ALT key pressed to insert special characters ( for example the most common ones such as `{` with ALT+123, `~` with ALT+126, or the tilde ~ with ALT+126, etc. ) do not work anymore. The latest working version is Microsoft.WindowsTerminal.Preview 1.20.11215.0, the next current one (1.21.1272.0) broke this functionality. ### Expected Behavior On previous versions the combination works raksati@wsl:$ showkey -a Press any keys - Ctrl-D will terminate this program ` 96 0140 0x60 ^D 4 0004 0x04 raksati@wsl:~$ ### Actual Behavior nothing is detected: raksati@wsl:$ showkey -a Press any keys - Ctrl-D will terminate this program ^D 4 0004 0x04 raksati@wsl:~$
claunia commented 2026-01-31 07:54:44 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (May 28, 2024):

Thanks for the report!

I suspect this might be related to PR #17067. There are a couple of places in the code that mention Alt-Numpad being handled in TSFInputControl. For example see here:

5d1cf1a704/src/cascadia/TerminalApp/TerminalPage.cpp (L1439-L1442)

But TSFInputControl has now been replaced, so perhaps that functionality was lost in the rewrite.

/cc @lhecker

@j4james commented on GitHub (May 28, 2024): Thanks for the report! I suspect this might be related to PR #17067. There are a couple of places in the code that mention Alt-Numpad being handled in `TSFInputControl`. For example see here: https://github.com/microsoft/terminal/blob/5d1cf1a704986808d09ae7729aaed39ce5d5f909/src/cascadia/TerminalApp/TerminalPage.cpp#L1439-L1442 But `TSFInputControl` has now been replaced, so perhaps that functionality was lost in the rewrite. /cc @lhecker
claunia commented 2026-01-31 07:54:44 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (May 28, 2024):

It works in conhost because that one doesn't rely on the WinRT TSF stack via TextInputHost, and so it'll receive the Alt+Numpad key regularly via WM_CHAR. The weirdest thing is that even if I remove the new TSF implementation entirely (doesn't get instantiated) it'll not fix the issue. Does that mean the only way to get Alt+Numpad keys in a WinUI app is by using CoreTextServicesManager? That'd be quite surprising and kind of sad, because we fundamentally can't use that class.

@lhecker commented on GitHub (May 28, 2024): It works in conhost because that one doesn't rely on the WinRT TSF stack via TextInputHost, and so it'll receive the Alt+Numpad key regularly via `WM_CHAR`. The weirdest thing is that even if I remove the new TSF implementation entirely (doesn't get instantiated) it'll not fix the issue. Does that mean the only way to get Alt+Numpad keys in a WinUI app is by using `CoreTextServicesManager`? That'd be quite surprising and kind of sad, because we fundamentally can't use that class.
claunia commented 2026-01-31 07:54:44 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (May 28, 2024):

Wow. Just after I wrote that I found that switching my keyboard layout to Korean or any other "complex" language fixes the issue. What in the heck!

@lhecker commented on GitHub (May 28, 2024): Wow. Just after I wrote that I found that switching my keyboard layout to Korean or any other "complex" language fixes the issue. What in the heck!
claunia commented 2026-01-31 07:54:44 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (May 29, 2024):

So, with all that said, I think it'd be way easier to just write our own Alt+Numpad support in TermControl from scratch. ConEmu got all the info we need: https://conemu.github.io/en/AltNumpad.html

If anyone wants to give it a shot, please do so!

Windows internals for the curious follow below:

I spent an unfathomable amount of time debugging this. 😄
This happens basically because the UWP implementation of TSF does not like its own non-UWP sibling very much and switches off when it sees it.

I tried solving this issue by adding this to TermControl:

// The remaining callbacks must be implemented because SendInput should only be called if there's no active composition.
const auto manager = Windows::UI::Text::Core::CoreTextServicesManager::GetForCurrentView();
_editContext = manager.CreateEditContext();
_editContext.TextUpdating([this](auto&&, auto&& args) { SendInput(args.Text()); });
_editContext.TextRequested([](auto&&, auto&&) {});
_editContext.SelectionRequested([](auto&&, auto&&) {});

(And NotifyFocusEnter() / NotifyFocusLeave() calls must be added of course.)
The problem is that for some mysterious reason these callbacks won't get called if our new TSF implementation got focus simultaneously (which it needs because otherwise we have no IME).

We call ITfDocumentMgr::CreateContext here:
13de7c6685/src/tsf/Implementation.cpp (L42)

It's implemented by CDocumentInputManager::CreateContext which calls QueryInterface on our ITfContextOwnerCompositionSink to check if it implements ITextInputClientOwner (86b4403f-c187-4a8b-b13e-c93c4ad1078c) and passes that as a bool to the CInputContext instance that's returned as the "context".

(The TSF context is mostly an adapter between the public msctf.h interfaces and the private implementation. We need our own context because we need TS_SS_TRANSITORY. See Implementation.cpp for lots of details about this.)

CInputContext::GetStatus then adapts our Implementation::GetStatus somewhat like this:

HRESULT CInputContext::GetStatus(TS_STATUS* status)
{
    YOUR_IMPLEMENTATION->GetStatus(status);
    if (YOU_IMPLEMENTED_THE_ITextInputClientOwner_INTERFACE?)
        status->dwStaticFlags |= TS_SS_UWPCONTROL;
    else
        status->dwStaticFlags &= ~TS_SS_UWPCONTROL;
}

The existence of this TS_SS_UWPCONTROL is what makes and breaks not just the Alt+Numpad support, but seemingly any support for any input whatsoever. If that flag is missing (= no TSF3), then somewhere something between TextInputHost and CoreTextEditContext breaks down. I couldn't quite figure out where and what exactly.

I think that's a bug in the TSF implementation. The lack of Alt+Numpad support is likely a fallout from this, because when that flag is missing and TextInputHost is not sending any input anymore, then it should also re-enable sending Alt+Numpad via WM_CHAR, just like how it works for regular Win32 applications.

In any case, if I pass any IUnknown instance as the ITextInputClientOwner in our Implementation, then that will fix the issue with the context that WinUI holds, because TextInputHost will then send messages again.

The only problem with all that is that it doesn't solve the focus problem: To make this work we need to give both WinUI's context (for Alt+Numpad) and our context (= our IME) focus at the same, which means that both will receive the same input at the same time. That's really really bad, because TSF3 doesn't use TS_SS_TRANSITORY and I don't want to deal with the terminal-specific issues that this results in.

@lhecker commented on GitHub (May 29, 2024): So, with all that said, I think it'd be _way_ easier to just write our own Alt+Numpad support in `TermControl` from scratch. ConEmu got all the info we need: https://conemu.github.io/en/AltNumpad.html If anyone wants to give it a shot, please do so! --- Windows internals for the curious follow below: I spent an unfathomable amount of time debugging this. 😄 This happens basically because the UWP implementation of TSF does not like its own non-UWP sibling very much and switches off when it sees it. I tried solving this issue by adding this to `TermControl`: ```cpp // The remaining callbacks must be implemented because SendInput should only be called if there's no active composition. const auto manager = Windows::UI::Text::Core::CoreTextServicesManager::GetForCurrentView(); _editContext = manager.CreateEditContext(); _editContext.TextUpdating([this](auto&&, auto&& args) { SendInput(args.Text()); }); _editContext.TextRequested([](auto&&, auto&&) {}); _editContext.SelectionRequested([](auto&&, auto&&) {}); ``` (And `NotifyFocusEnter()` / `NotifyFocusLeave()` calls must be added of course.) The problem is that for some mysterious reason these callbacks won't get called if our new TSF implementation got focus simultaneously (which it needs because otherwise we have no IME). We call `ITfDocumentMgr::CreateContext` here: https://github.com/microsoft/terminal/blob/13de7c668577ae270ce9528d6a895fd169ece7cc/src/tsf/Implementation.cpp#L42 It's implemented by `CDocumentInputManager::CreateContext` which calls `QueryInterface` on our `ITfContextOwnerCompositionSink` to check if it implements `ITextInputClientOwner` (`86b4403f-c187-4a8b-b13e-c93c4ad1078c`) and passes that as a `bool` to the `CInputContext` instance that's returned as the "context". (The TSF context is mostly an adapter between the public msctf.h interfaces and the private implementation. We need our own context because we need `TS_SS_TRANSITORY`. See `Implementation.cpp` for lots of details about this.) `CInputContext::GetStatus` then adapts our `Implementation::GetStatus` somewhat like this: ```cpp HRESULT CInputContext::GetStatus(TS_STATUS* status) { YOUR_IMPLEMENTATION->GetStatus(status); if (YOU_IMPLEMENTED_THE_ITextInputClientOwner_INTERFACE?) status->dwStaticFlags |= TS_SS_UWPCONTROL; else status->dwStaticFlags &= ~TS_SS_UWPCONTROL; } ``` The existence of this `TS_SS_UWPCONTROL` is what makes and breaks not just the Alt+Numpad support, but seemingly any support for any input whatsoever. If that flag is missing (= no TSF3), then somewhere something between `TextInputHost` and `CoreTextEditContext` breaks down. I couldn't quite figure out where and what exactly. I think that's a bug in the TSF implementation. The lack of Alt+Numpad support is likely a fallout from this, because when that flag is missing and `TextInputHost` is not sending any input anymore, then it should also re-enable sending Alt+Numpad via `WM_CHAR`, just like how it works for regular Win32 applications. In any case, if I pass any `IUnknown` instance as the `ITextInputClientOwner` in **our** `Implementation`, then that will fix the issue with the context that WinUI holds, because `TextInputHost` will then send messages again. The only problem with all that is that it doesn't solve the focus problem: To make this work we need to give both WinUI's context (for Alt+Numpad) and our context (= our IME) focus at the same, which means that both will receive the same input at the same time. That's really really bad, because TSF3 doesn't use `TS_SS_TRANSITORY` and I don't want to deal with the terminal-specific issues that this results in.
claunia commented 2026-01-31 07:54:45 +00:00
Author
Owner
Copy Link

@inoperable commented on GitHub (Jul 4, 2024):

If this is not a joke, can i quote your rationale?

@inoperable commented on GitHub (Jul 4, 2024): If this is _not_ a joke, can i quote your rationale?
claunia commented 2026-01-31 07:54:45 +00:00
Author
Owner
Copy Link

@inoperable commented on GitHub (Jul 4, 2024):

   ╔═════╗
   ║ Duh ║
o.O╜═════╝

So, whats the best way to achieve something more complex, say √² or https://brltty.app/details.html

...

@inoperable commented on GitHub (Jul 4, 2024): ``` ╔═════╗ ║ Duh ║ o.O╜═════╝ ``` So, whats the best way to achieve something more complex, say √² or https://brltty.app/details.html ...
claunia commented 2026-01-31 07:54:45 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Jul 8, 2024):

Rationale for what? And what exactly did you feel like was a joke?

The way you're phrasing it, it sounds like you believe I have no intention of seeing this fixed, but literally the very first paragraph of what I wrote explains how we should do it. 😅

@lhecker commented on GitHub (Jul 8, 2024): Rationale for what? And what exactly did you feel like was a joke? The way you're phrasing it, it sounds like you believe I have no intention of seeing this fixed, but literally the very first paragraph of what I wrote explains how we should do it. 😅
claunia commented 2026-01-31 07:54:45 +00:00
Author
Owner
Copy Link

@inoperable commented on GitHub (Jul 8, 2024):

Right. Hast je ein terminal verwendet in deinem Leben der weniger mühsam
ist als er?

On Mon, Jul 8, 2024, 19:38 Leonard Hecker @.***> wrote:

Rationale for what? And what exactly did you feel like was a joke?

The way you're phrasing it, it sounds like you believe I have no intention
of seeing this fixed, but literally the very first paragraph of what I
wrote explains how we should do it. 😅

—
Reply to this email directly, view it on GitHub
https://github.com/microsoft/terminal/issues/17327#issuecomment-2214796236,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAL7SAW5DGMZ3H2N643JBXLZLLFBBAVCNFSM6AAAAABIMKLFJKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMJUG44TMMRTGY
.
You are receiving this because you commented.Message ID:
@.***>

@inoperable commented on GitHub (Jul 8, 2024): Right. Hast je ein terminal verwendet in deinem Leben der weniger mühsam ist als er? On Mon, Jul 8, 2024, 19:38 Leonard Hecker ***@***.***> wrote: > Rationale for what? And what exactly did you feel like was a joke? > > The way you're phrasing it, it sounds like you believe I have no intention > of seeing this fixed, but literally the very first paragraph of what I > wrote explains how we should do it. 😅 > > — > Reply to this email directly, view it on GitHub > <https://github.com/microsoft/terminal/issues/17327#issuecomment-2214796236>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAL7SAW5DGMZ3H2N643JBXLZLLFBBAVCNFSM6AAAAABIMKLFJKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMJUG44TMMRTGY> > . > You are receiving this because you commented.Message ID: > ***@***.***> >
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 In-PR Issue-Bug Needs-Tag-Fix Priority-3 Product-Terminal
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#21780
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?