Alt doesn't work for most of the non-alphabetic ASCII control characters (Alt-Ctrl-[, Alt-Ctrl-\, Alt-Ctrl-], Alt-Ctrl-^)

[aimfiz]

Windows Terminal version

1.16.10262.0

Windows build number

10.0.22621

Other Software

No response

Steps to reproduce

wsl
showkey -a

[type Ctrl-A, Alt-Ctrl-A, Ctrl-], Alt-Ctrl-], Ctrl-6, Alt-Ctrl-6]

Expected Behavior

^A        1 0001 0x01
^[^A     27 0033 0x1b
          1 0001 0x01
^]       29 0035 0x1d
^[^]     27 0033 0x1b
         29 0035 0x1d
^^       30 0036 0x1e
^[^^     27 0033 0x1b
         30 0036 0x1e

Generally, for any key press that produces the character code C in the range 0 through 127, the same key press but with the Alt key down should produce the character code 27 (i.e., escape) followed by the character code C. (Unless, of course, there is a conflicting, explicit binding. There's a default binding for Alt-Ctrl-6, but removing it doesn't help.)

Actual Behavior

^A        1 0001 0x01
^[^A     27 0033 0x1b
          1 0001 0x01
^]       29 0035 0x1d
^^       30 0036 0x1e

[aimfiz]

The handling of un-Alt-ed control keys for the seven ASCII non-alphabetic control codes (0, 27-31, and 127) works fine, but the addition of Alt is broken for most of them. Specifically, I'm seeing:

key:    Ctrl-key generates:     Alt-Ctrl-key generates:
`~      0                       nothing
space   0                       27 0
2@      0                       27 0
3#      27                      nothing
4$      28                      nothing
5%      29                      nothing
6^      30                      nothing
7&      31                      nothing
8*      127                     nothing
[{      27                      nothing
\|      28                      nothing
]}      29                      nothing
/?      31                      27 31
backsp 127                      27 127

The problem seems to be in TerminalInput::HandleKey in src/terminal/input/terminalInput.cpp

[aimfiz]

A related issue is that control-minus should generate code 31, not 13.

In other words, because there is no ASCII control-minus, it's helpful and expected that one can type control-underscore using only the control key and the key with an underscore on it, without having to press shift as well. But it is unhelpful and not expected by anyone that pressing control-minus will generate control-M a/k/a carriage-return.

(By the same logic, control-slash (i.e., control-? without a shift) should produce 127, not 31 (i.e., control-?, not control-underscore). But that illogical binding has a few decades of precedent in xterm, so people do expect it.)

[carlos-zamora]

Thanks for filing this! Surprised we haven't heard of this one before!

[aimfiz]

This issue is the more general case of issue #12555 (ctrl-alt-\ is ignored in WSL). As pointed out there, you can work around the problem by explicitly specifying a sendInput action for each key combination that doesn't work, e.g.:

        {
            "command": 
            {
                "action": "sendInput",
                "input": "\u001b\u001c"
            },
            "keys": "ctrl+alt+\\"
        },