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

Feature request: Set IME input mode to English when a Windows Terminal window is opened #17042

New Issue
Closed
opened 2026-01-31 05:30:40 +00:00 by claunia · 7 comments
claunia commented 2026-01-31 05:30:40 +00:00
Owner
Copy Link

Originally created by @gexgd0419 on GitHub (Mar 21, 2022).

Description of the new feature/enhancement

I'm using the Microsoft Chinese IMEs, and when I open a Windows Terminal window, the input mode will be set to Chinese.

I know that's because the IME's "default mode" is set to Chinese (which is also the system default setting). If I change its "default mode" to English then the input mode will be English when I open Windows Terminal.

But I also noticed that even with the "default mode" set to Chinese, if you open Command Prompt (or other programs hosted by conhost.exe), the IME mode will still be switched to English, because users are more likely to input English texts.

So setting the input mode to English when Windows Terminal is launched would be helpful, as most command line texts are in English.

For Sougou Pinyin IME users: seems that Sougou Pinyin does not respect the "default input mode" set by those programs, because opening a Command Prompt window won't change its input mode to English.

I actually found a similar issue #1304 that further requested to restore input mode to English each time users hit Enter or Esc. That may be even better, although changing input mode so often might confuse some users. Personally I just want Windows Terminal to have English input mode on startup like what conhost does, so I can type in commands immediately.

Originally created by @gexgd0419 on GitHub (Mar 21, 2022). # Description of the new feature/enhancement I'm using the Microsoft Chinese IMEs, and when I open a Windows Terminal window, the input mode will be set to Chinese. I know that's because the IME's "default mode" is set to Chinese (which is also the system default setting). If I change its "default mode" to English then the input mode will be English when I open Windows Terminal. But I also noticed that even with the "default mode" set to Chinese, if you open Command Prompt (or other programs hosted by conhost.exe), the IME mode will still be switched to English, because users are more likely to input English texts. So setting the input mode to English when Windows Terminal is launched would be helpful, as most command line texts are in English. For Sougou Pinyin IME users: seems that Sougou Pinyin does not respect the "default input mode" set by those programs, because opening a Command Prompt window won't change its input mode to English. I actually found a similar issue #1304 that further requested to restore input mode to English each time users hit Enter or Esc. That may be even better, although changing input mode so often might confuse some users. Personally I just want Windows Terminal to have English input mode on startup like what conhost does, so I can type in commands immediately.
claunia commented 2026-01-31 05:30:43 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Mar 21, 2022):

If this is something that conhost already does, then this should be fairly trivial to implement for the Terminal, and it'd be all the precedent needed to do it. I'm worried that this is something that the IME does on behalf of conhost - detecting that conhost is the foreground window and then switching automatically.

If that's the case, this might be quite a bit harder to fix, requiring a fix in the OS itself.

@zadjii-msft commented on GitHub (Mar 21, 2022): If this is something that conhost already does, then this should be fairly trivial to implement for the Terminal, and it'd be all the precedent needed to do it. I'm worried that this is something that the IME does on behalf of conhost - detecting that conhost is the foreground window and then switching automatically. If that's the case, this might be quite a bit harder to fix, requiring a fix in the OS itself.
claunia commented 2026-01-31 05:30:43 +00:00
Author
Owner
Copy Link

@YanceyChiew commented on GitHub (Apr 14, 2022):

I didn't go deep, but have done a little testing to try and solve the same problem.

In terms of test results, there should be at least two(edited: maybe only one) factors affecting the default input mode for window programs:

  • When the window class is ConsoleWindowClass, the input mode will be set to english regardless of the default value.(edited: There was an error in the previous test, because specifying WindowClass alone was far from enough to create an interactive console window, therefore, the above conclusions are only inferences based on limited indirect tests, which are in fact wrong. Finally, it was found that the real impact was the process name of conhost.exe, If it was renamed, any shells hosted on it will no longer automatically switch to the English input mode.)

  • When the process name is cmd.exe, powershell.exe, bash.exe or conhost.exe, the input mode will be set to english regardless of the default value. (edited: supplement known process name)

Looks more like it's determined by the Microsoft Pinyin itself, especially the second. When I rename other programs like notepad.exe to cmd.exe, it will accept English input by default.

For the first item, because there is no language related field in WNDCLASS or WNDCLASSEX structure, so I can only think that this ConsoleWindowClass has an extra contract with the system or Microsoft Pinyin. (edited: It doesn't matter because the first item above does not actually affect.)

The input area window class of windows terminal is Windows.UI.Input.InputSite.WindowClass,
I also didn't find the relevant settings, so I gave up.

The example in this link might be useful, but I didn't test it.

@YanceyChiew commented on GitHub (Apr 14, 2022): I didn't go deep, but have done a little testing to try and solve the same problem. In terms of test results, there should be at least ~~two~~_(edited: maybe only one)_ factors affecting the default input mode for window programs: - ~~When the window class is ConsoleWindowClass, the input mode will be set to english regardless of the default value.~~_(edited: There was an error in the previous test, because specifying WindowClass alone was far from enough to create an interactive console window, therefore, the above conclusions are only inferences based on limited indirect tests, which are in fact wrong. Finally, it was found that the real impact was the process name of conhost.exe, If it was renamed, any shells hosted on it will no longer automatically switch to the English input mode.)_ - When the process name is cmd.exe, powershell.exe, bash.exe or conhost.exe, the input mode will be set to english regardless of the default value. _(edited: supplement known process name)_ Looks more like it's determined by the Microsoft Pinyin itself, especially the second. When I rename other programs like notepad.exe to cmd.exe, it will accept English input by default. ~~For the first item, because there is no language related field in WNDCLASS or WNDCLASSEX structure, so I can only think that this ConsoleWindowClass has an extra contract with the system or Microsoft Pinyin.~~ _(edited: It doesn't matter because the first item above does not actually affect.)_ The input area window class of windows terminal is Windows.UI.Input.InputSite.WindowClass, I also didn't find the relevant settings, so I gave up. _The example in this [link](https://docs.microsoft.com/en-us/windows/apps/design/globalizing/manage-language-and-region#app-manifest-language-list) might be useful, but I didn't test it._
claunia commented 2026-01-31 05:30:43 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Apr 14, 2022):

Well, that's certainly great research! It's maybe a little troubling that this is something that seems to be outside our codebase. If this is something that's truly just a heuristic by Microsoft Pinyin, that just means it's gonna be less likely we can just patch that on our side.

@zadjii-msft commented on GitHub (Apr 14, 2022): Well, that's certainly great research! It's maybe a little troubling that this is something that seems to be outside our codebase. If this is something that's truly just a heuristic by Microsoft Pinyin, that just means it's gonna be less likely we can just patch that on our side.
claunia commented 2026-01-31 05:30:43 +00:00
Author
Owner
Copy Link

@YanceyChiew commented on GitHub (Apr 21, 2022):

Well, that's certainly great research! It's maybe a little troubling that this is something that seems to be outside our codebase. If this is something that's truly just a heuristic by Microsoft Pinyin, that just means it's gonna be less likely we can just patch that on our side.

I think I found a way:

in src\cascadia\TerminalControl\TSFInputControl.cpp:41:

        _editContext.InputScope(CoreTextInputScope::Text);

Just simply change the CoreTextInputScope::Text to CoreTextInputScope::AlphanumericHalfWidth should work.

  • CoreTextInputScope::AlphanumericHalfWidth makes the input box accept English by default, and can be manually changed to Chinese Pinyin with the shift key, which is exactly the effect we want.
    Although its name limits the characters to half-width, the input method can still enter full-width characters.
  • CoreTextInputScope::Password can also make the input box accept English input by default, but it will prevent the input method from being manually switched to Chinese Pinyin.

NOTICE: I have not actually tested the above code in this project, but completed the feasibility verification in another simple project which is just for testing, then I searched the entire microsoft/terminal project and found the only place InputScope appears and wrote this comment.

@YanceyChiew commented on GitHub (Apr 21, 2022): > Well, that's certainly great research! It's maybe a little troubling that this is something that seems to be outside our codebase. If this is something that's truly just a heuristic by Microsoft Pinyin, that just means it's gonna be less likely we can just patch that on our side. I think I found a way: [in src\cascadia\TerminalControl\TSFInputControl.cpp:41:](https://github.com/microsoft/terminal/blob/87f5034db1eb0102358d05eeff82ebcc8032c9be/src/cascadia/TerminalControl/TSFInputControl.cpp#L41) ``` cpp _editContext.InputScope(CoreTextInputScope::Text); ``` Just simply change the `CoreTextInputScope::Text` to `CoreTextInputScope::AlphanumericHalfWidth` should work. - `CoreTextInputScope::AlphanumericHalfWidth` makes the input box accept English by default, and can be manually changed to Chinese Pinyin with the shift key, which is exactly the effect we want. Although its name limits the characters to half-width, the input method can still enter full-width characters. - `CoreTextInputScope::Password` can also make the input box accept English input by default, but it will prevent the input method from being manually switched to Chinese Pinyin. **NOTICE:** I have not actually tested the above code in this project, but completed the feasibility verification in another simple project which is just for testing, then I searched the entire [microsoft/terminal](https://github.com/microsoft/terminal) project and found the only place InputScope appears and wrote this comment.
claunia commented 2026-01-31 05:30:43 +00:00
Author
Owner
Copy Link

@YanceyChiew commented on GitHub (Apr 21, 2022):

I have actually verified in this project that _editContext.InputScope(CoreTextInputScope::AlphanumericHalfWidth) works as expected, the remaining question is whether this change will cause dissatisfaction among some other users?

Or to be on the safe side, make the inputScope customizable through the configuration file maybe a better choice, I can handle it if necessary.

@YanceyChiew commented on GitHub (Apr 21, 2022): I have actually verified in this project that `_editContext.InputScope(CoreTextInputScope::AlphanumericHalfWidth)` works as expected, the remaining question is whether this change will cause dissatisfaction among some other users? Or to be on the safe side, make the inputScope customizable through the configuration file maybe a better choice, I can handle it if necessary.
claunia commented 2026-01-31 05:30:44 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (May 3, 2022):

We can wait to see how users react. We only have to add a setting if they complain. 😄 Thanks!

@DHowett commented on GitHub (May 3, 2022): We can wait to see how users react. We only have to add a setting if they complain. :smile: Thanks!
claunia commented 2026-01-31 05:30:44 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (May 24, 2022):

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

Handy links:

@ghost commented on GitHub (May 24, 2022): :tada:This issue was addressed in #13028, which has now been successfully released as `Windows Terminal Preview v1.14.143`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v1.14.143) * [Store Download](https://www.microsoft.com/store/apps/9n8g5rfz9xk3?cid=storebadge&ocid=badge)
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-i18n Area-Input Issue-Task 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#17042
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?