starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-09-25 08:24:54 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Ctrl + Alt + number keys not working in 1.7.1033.0 with Danish keyboard #13576

New Issue
Closed
opened 2026-01-31 03:46:14 +00:00 by claunia · 4 comments
claunia commented 2026-01-31 03:46:14 +00:00
Owner
Copy Link

Originally created by @oback on GitHub (Apr 20, 2021).

On Danish layout keyboards several characters are accessed through the Alt Gr or Ctrl+Alt modifier keys (either will usually work). For instance, [ is typed with AltGr + 8 or Ctrl + Alt + 8. Due to the various placement of the keys, it's nice to have both options, since for example AltGr + 8 can be awkward to reach.

After wt was upgraded to 1.7.1033.0, the Ctrl + Alt combinations no longer work. AltGr still works, and the Ctrl + Alt options also work directly in cmd.exe and powershell terminals.

If I uninstall the latest version and manually install version 1.6.10571.0, the Ctrl + Alt modifiers work again.

Configuration:
Windows Terminal 1.7.1033.0
Danish QWERTY keyboard layout

Originally created by @oback on GitHub (Apr 20, 2021). On Danish layout keyboards several characters are accessed through the `Alt Gr` or `Ctrl+Alt` modifier keys (either will usually work). For instance, `[` is typed with `AltGr + 8` or `Ctrl + Alt + 8`. Due to the various placement of the keys, it's nice to have both options, since for example `AltGr + 8` can be awkward to reach. After wt was upgraded to 1.7.1033.0, the `Ctrl + Alt` combinations no longer work. `AltGr` still works, and the `Ctrl + Alt` options also work directly in cmd.exe and powershell terminals. If I uninstall the latest version and manually install version 1.6.10571.0, the `Ctrl + Alt` modifiers work again. Configuration: Windows Terminal 1.7.1033.0 Danish QWERTY keyboard layout
claunia added the Needs-TriageIssue-BugArea-InputProduct-Terminal labels 2026-01-31 03:46:14 +00:00
claunia commented 2026-01-31 03:46:15 +00:00
Author
Owner
Copy Link

@oback commented on GitHub (Apr 21, 2021):

After looking into it some more, I realized that those key combinations are bound to tab switching. If I unbind the keys I get the old behavior back:

        { "command": "unbound", "keys": "ctrl+alt+1" },
        { "command": "unbound", "keys": "ctrl+alt+2" },
        { "command": "unbound", "keys": "ctrl+alt+3" },
        { "command": "unbound", "keys": "ctrl+alt+4" },
        { "command": "unbound", "keys": "ctrl+alt+5" },
        { "command": "unbound", "keys": "ctrl+alt+6" },
        { "command": "unbound", "keys": "ctrl+alt+7" },
        { "command": "unbound", "keys": "ctrl+alt+8" },
        { "command": "unbound", "keys": "ctrl+alt+9" }

As far as I can tell the same key bindings existed in the previous version. I'm not sure what has changed, but I have a reasonable workaround for now.

@oback commented on GitHub (Apr 21, 2021): After looking into it some more, I realized that those key combinations are bound to tab switching. If I unbind the keys I get the old behavior back: ``` { "command": "unbound", "keys": "ctrl+alt+1" }, { "command": "unbound", "keys": "ctrl+alt+2" }, { "command": "unbound", "keys": "ctrl+alt+3" }, { "command": "unbound", "keys": "ctrl+alt+4" }, { "command": "unbound", "keys": "ctrl+alt+5" }, { "command": "unbound", "keys": "ctrl+alt+6" }, { "command": "unbound", "keys": "ctrl+alt+7" }, { "command": "unbound", "keys": "ctrl+alt+8" }, { "command": "unbound", "keys": "ctrl+alt+9" } ``` As far as I can tell the same key bindings existed in the previous version. I'm not sure what has changed, but I have a reasonable workaround for now.
claunia commented 2026-01-31 03:46:16 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Apr 21, 2021):

Huh. That's weird. I don't think we merged anything into 1.7 that had anything to do with the input handling, especially not altgr handling. 91f68e2914 is the closest to touching that, and I don't think that should have broke it.

@lhecker you want to give this a look?

@zadjii-msft commented on GitHub (Apr 21, 2021): Huh. That's weird. I don't _think_ we [merged anything into 1.7](https://github.com/microsoft/terminal/compare/v1.7.1033.0...release-1.6) that had anything to do with the input handling, especially not altgr handling. 91f68e2914dbdde338c58e0ab4095bee49d1470d is the closest to touching that, and I don't think that should have broke it. @lhecker you want to give this a look?
claunia commented 2026-01-31 03:46:16 +00:00
Author
Owner
Copy Link

@oback commented on GitHub (Apr 21, 2021):

Huh. That's weird. I don't think we merged anything into 1.7 that had anything to do with the input handling, especially not altgr handling.

Wouldn't it be more correct to diff with 1.6 as the base? That seems to be a bit bigger - in particular it includes #5272 and #8870.
Edit: Updated text, changed reference to the PR instead of the issue.

But I would almost say the current behavior is actually correct. The ctrl+alt+<number> inputs are now hidden by (default) key bindings, but from what I can tell this is the desired behavior. If I bind a key to another normal input (like { "command": "closeWindow", "keys": "a" }, for an extreme example), then the command fires instead of the input. For some reason ctrl + alt + <number> gave priority to the input over the command binding in previous versions, whereas it is now in line with other inputs.

@oback commented on GitHub (Apr 21, 2021): > Huh. That's weird. I don't _think_ we [merged anything into 1.7](https://github.com/microsoft/terminal/compare/v1.7.1033.0...release-1.6) that had anything to do with the input handling, especially not altgr handling. Wouldn't it be more correct to diff with [1.6 as the base?](https://github.com/microsoft/terminal/compare/release-1.6...v1.7.1033.0) That seems to be a bit bigger - in particular it includes #5272 and #8870. *Edit: Updated text, changed reference to the PR instead of the issue.* But I would almost say the current behavior is actually correct. The `ctrl+alt+<number>` inputs are now hidden by (default) key bindings, but from what I can tell this is the desired behavior. If I bind a key to another normal input (like `{ "command": "closeWindow", "keys": "a" },` for an extreme example), then the command fires instead of the input. For some reason `ctrl + alt + <number>` gave priority to the input over the command binding in previous versions, whereas it is now in line with other inputs.
claunia commented 2026-01-31 03:46:16 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Apr 21, 2021):

I've installed the "Danish" language and keyboard layout, as well as version 1.6.10571.0 of Windows Terminal.

Unfortunately I was unable to reproduce the old behavior you describe: Even in version 1.6 Ctrl+Alt+<num> will switch tabs for me instead of working as an alias for AltGr.

But I would almost say the current behavior is actually correct.

That's right and the "unbound" commands your posted earlier are the correct approach to restore the Ctrl+Alt behavior you expect. The fact that Ctrl+Alt+<num> is used to switch tabs might be considered an unfortunate choice from the past, but we currently stick with it, in order to not break the workflow for users who're already used to that.

And due to that I'd like to take the liberty to close this issue for now. 🙂

@lhecker commented on GitHub (Apr 21, 2021): I've installed the "Danish" language and keyboard layout, as well as version 1.6.10571.0 of Windows Terminal. Unfortunately I was unable to reproduce the old behavior you describe: Even in version 1.6 `Ctrl+Alt+<num>` will switch tabs for me instead of working as an alias for AltGr. > But I would almost say the current behavior is actually correct. That's right and the "unbound" commands your posted earlier are the correct approach to restore the Ctrl+Alt behavior you expect. The fact that `Ctrl+Alt+<num>` is used to switch tabs might be considered an unfortunate choice from the past, but we currently stick with it, in order to not break the workflow for users who're already used to that. And due to that I'd like to take the liberty to close this issue for now. 🙂
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-Input Issue-Bug Needs-Triage 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#13576
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?