keybindings of dead keys using AltGr+X

[gpotter2]

Windows Terminal version (or Windows build number)

1.9.1445.0

Steps to reproduce

• Use a keyboard that has a dead key hidden behind a altgr+X combo. (This is the case for instance on AZERTY keyboards for the ~ or the ` keys: the former is a dead key that requires altGr+~ or ctrl+alt+~ (the ~ is located on the 2 key, the ` on the 7 key))

The AZERTY keyboard for context:

• Bind that dead key to some action. for instance, I use those two keybindings to "un-deadify" some keys:

{
    "command": {
        "action": "sendInput",
        "input": "^"
    },
    "keys": "^"
},
{
    "command": {
        "action": "sendInput",
        "input": "~"
    },
    "keys": "ctrl+alt+~"
}

Actual Behavior

Both ^ and ~ keys are dead keys.

• If I type ^, it works great: the ^ shows up instantly and doesn't act as a dead key.
• If try to print a ~ it does work great when doing ctrl+alt+~ (what altgr is an alias of), but not when using altGr+~:
  • when doing ctrl+alt+~: the key shows instantly
  • when doing altGr+~: the key still acts dead (I need to add a space for ~ to show up)
• I made sure that altGrAliasing was turned on.

Comments

This issue follows my previous #5784 issue. TBF, this is the edge case of an edge case, and I would understand if this never got fixed... I'm just secretly hoping for another @lhecker miracle 😄 but can probably live without it

[eElor]

Thanks for the "un-deadifying-of-keys" idea. I almost got crazy today after updating from 1.6.10571.0 to 1.7.X / 1.8.X / 1.9.X and noticing that despite having altGrAliasing turned on, I couldn't input any of { [ ] by Ctrl-Alting them. Reading through the issues, I noticed this problem pops up every now and then...
Following solved the issue (not a very nice solution though 🙈 Probably there are also other dead keys I will need to wake up ... )

...
         {
            "command": {
                "action": "sendInput",
                "input": "{"
            },
            "keys": "{"
        },
        {
            "command": {
                "action": "sendInput",
                "input": "["
            },
            "keys": "["
        },
        {
            "command": {
                "action": "sendInput",
                "input": "]"
            },
            "keys": "]"
        }
...

[lhecker]

@gpotter2 What language are you using the AZERTY layout with? For French AZERTY AltGr+9 (^) is not a dead key.

[lhecker]

Oh and there's also this comment:

terminal/src/cascadia/TerminalControl/TermControl.cpp

Lines 885 to 887 in d7f2a39

	// GH#2235: Terminal::Settings hasn't been modified to differentiate
	// between AltGr and Ctrl+Alt yet.
	// -> Don't check for key bindings if this is an AltGr key combination.

[gpotter2]

@gpotter2 What language are you using the AZERTY layout with? For French AZERTY AltGr+9 (^) is not a dead key.

There is another one accessible with a single keypress (in red on the picture, near the enter key)

[lhecker]

@gpotter2 Just to explain my previous comment a bit better: This issue exists due to #2235
For instance if you use a German keyboard Ctrl+Alt+7 and AltGr+7 will both produce the rather important character {. Since WT's settings don't differentiate between left and right Alt, it doesn't differentiate between Ctrl+Alt and AltGr. #2235 prevents AltGr+combinations from ever reaching your keybinding settings, allowing you to have a key binding for Ctrl+Alt+7 (aka "focus tab 7") while simultaneously being able to press AltGr+7 to write a {.

Fixing this issue is very complicated and quite likely requires us to change the meaning of the "Ctrl" and "Alt" keywords when writing key bindings, in order to resolve the conflict with AltGr.
I don't know what the best course of action is. Preferably it should be something that doesn't break existing work flows of our users.

[gpotter2]

I see. That's very clear thank you. Understandably being able to bind Ctrl+Alt+? to shortcuts is much more important than overriding altgr shortcuts.

The obvious solution would be for WSL to be able to differentiate altgr and alt but that's of course more easily said than done.