Terminal: WT should not define mappings for system keybinding CTRL + ALT + <n>

[plastikfan]

Currently, WT, defines default mapping for CTRL + SHIFT + \bad mapping is that on my setup, # symbol can not be typed in Windows terminal. This is a system level keybinding that works in all other applications, so having WT redefine that to something else is not best option for end users, particularly non US users. I imagine that users in different parts of the world with different bindings can have other similar types of issues, but I can only report on my experience.

A chat with Kayla Cinnamon on Twitter has revealled that those bindings can be overridden in the settings.json as follows:

{ "command": null, "keys": "ctrl+shift+3" }

inside the "keybindings": array setting

Environment

Windows build number: [run `[Environment]::OSVersion` for powershell, or `ver` for cmd]
Windows Terminal version (if applicable):
λ [Environment]::OSVersion

Platform ServicePack Version      VersionString
-------- ----------- -------      -------------
 Win32NT             10.0.19041.0 Microsoft Windows NT 10.0.19041.0
Any other software?

Steps to reproduce

This perhaps requires specific hardware to reproduce, so I'll describe what I'm currently using:

• A macbook pro (Mid 2014 model), running windows 10(may 2004) via bootcamp
• A UK external mechanical apple keyboard

Language keyboard settings:
Time zone: UTC+0 (London)
Region: United Kingdom
Region Format: English UK
Windows display language: English UK
Preferred Language English (UK)

Language Options -> Keyboards:
United Kingdom (Apple)

PLEASE NOTE: I've had to remove the windows keyboard (under Keyboards), because having it defined makes using the system un-predictable and automatic keyboard switching being invoke accidentally and causing problems, particularly with not being able to type the # symbol, and @ symbol being swapped over with ", and other differences.

(I have attached some screen shots to help document my settings)

And a couple of pictures of my external keybaord and the inbuilt keyboard with focus on key no 3(£#)

Expected behavior

Windows terminal should not be remapping system level bindings, particularly for low value features like tab switching overriding essential functionality like being able to access the # symbol and for other internation users, these could be other symbols essential to them. This is particluarly an issue for non windows keyboards, ie apple keyboards used with windows bootcamp.

I don't want the # symbol to be tampered with in any way.

This misbehaviour is intermittent too, which makes diagnosing this issue more problematic.

Actual behavior

When the keybind is failing, I can't type the # symbol with CTRL + ALT + 3, which is a system wide binding that works for every other application running in windows; it's only Windows Terminal that is doing something different.

The work around provided by Kayla (redefining the keybinding to null), is a sticking plaster. Firstly I don't know if this works consistently yet as I've only just set it and this is an intermittent issue. Really, CTRL + ALT + \

[zadjii-msft]

I'm just gonna summon our resident AltGr expert @lhecker

[lhecker]

I admit that the choice of Ctrl+Alt+n is slightly unlucky, since many international keyboards have and heavily make use of an AltGr key, for which Ctrl+Alt is an alias on Windows. We kind of knew about this already, but WT now uses those bindings for tab switching and it's certain that quite a few users would be upset if we'd simply removed those. As such I'd say that this issue will not be resolved anytime soon. I believe our best bet is to wait for https://github.com/microsoft/terminal/pull/6732 as it'll add a neat, new & alternative way for tab switching. With that in place we could carefully consider removing the Ctrl+Alt+n bindings by default.

In the meantime the # symbol can be untampered and the show continue by adding the following to the keybindings array within your config file. 🙂

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

[zadjii-msft]

@plastikfan does the json sample that @lhecker provided work for you to unbind the Ctrl+Alt+N keys and restore the functionality of # for you?

[msftbot[bot]]

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.

[plastikfan]

Yeah that mapping adjustment works, but the way I see it, it is a poor work around to cover up a poor decision, to implement a feature knowing that it is going to cause a problem for some users. Not happy! I wouldn't mind you considering a solution even if it's not high priority. The main point I have an issue with is not taking into account all users. If you're going to make a decision like that, then please document it.

[zadjii-msft]

You know what, we'll make sure to avoid binding anything else to ctrl+alt+ in the future. That's about the best we can do at this point - we don't want to break all the users who are currently depending on the existing ctrl+alt+ keybindings.

Thanks for bringing this to our attention!