Ctrl+Keys that can't be encoded as VT should still fall through as the unmodified character

[mattaferreira]

Environment

Windows build number: Microsoft Windows [Version 10.0.18362.418]
Windows Terminal version (if applicable): Version: 0.6.2951.0

Any other software?
WSL2

Steps to reproduce

It is very convenient to use emacs to reproduce this, since it can show received key sequences

1. All shortcuts in Terminal need to be unbound, so open settings and set every command in keybindings to null.
2. Open emacs
3. Press C-h l (for non-emacs users, Control+h then L by itself). This shows the most recent key sequences at the bottom.
4. Press C-, or C-. or C-; or C-'
5. Press C-h l again. None of the above sequences are displayed.

It is possible to bind one of those keys to an actual emacs command, just to make sure emacs isn't dropping a sequence it doesn't care about, but the result should be the same.

Note that pressing the four above punctuation keys by themselves, or combined with Shift, works as expected.

Expected behavior

C-h l should display all of the entered sequences. If a command is bound, it should execute.

Actual behavior

No sequences are displayed, no commands execute.

[zadjii-msft]

Huh. Curiously, I don't think those keys are possible to bind even in gnome-terminal:

On the left, I have a gnome-terminal window running on WSL via vcxsrv. Even there, these keystrokes are only coming through as ,, ., ;, and '. I was under the impression that these keystrokes were not things that were possible to encode as VT sequences.

Maybe this is something that needs more support, something like the xterm extended keyboard modifiers (which was proposed earlier on the repo here).

For linking purposes, #879 is a related problem.

I'm curious what @egmontkob and @j4james's thoughts are on the subject

(edit: I'm marking this for conhost, not the Terminal, since it A: doesn't work in conhost and should, and B: fixing this for conhost should just fix it for the Terminal).

[egmontkob]

C-h

This is already problematic, since depending on the erase character (see e.g. gnome-terminal's Compatibility prefs for one side of the story, and stty erase for the other side) this might be the same as Backspace.

these keystrokes are only coming through as ,, ., ;, and '

Yup, just as there's no Ctrl + accented letters, and such. The 0x00..0x1F chars are traditionally denoted as Ctrl+letter and such, as you know, and this is exactly what the Ctrl modifier does in terminals by default. (It's a computer-friendly and not a user-friendly behavior.)

xterm extended keyboard modifiers

That's the next thing that occurred to me. I really don't like this protocol, see here.

Kitty has an extension, maybe iTerm2 too, and some folks on Terminal WG began to design a new one. Alas I'm really not convinced that they have enough experience with keyboard handling (including int'l layouts and whatnot) to do it properly. This looks like a task to me that would require way more studying of the state of the art than they did.

So, I don't know what could be a proper solution here. Mind you, we don't support any extension like this in g-t, and people hardly ever complain. So maybe you can wait with it for a year or two :)

[j4james]

I don't think our handling of these keys is quite correct. Technically something like Ctrl-. should produce a . rather than nothing (assuming we're following XTerm's behaviour), but I don't suppose that's going to make a whole lot of difference to someone wanting it to map to a unique sequence.

Also, it's worth noting that we can behave differently with an international keyboard. For example, Ctrl-' produces NUL on a UK keyboard, I'm guessing that's because Shift-' is @, but that's not the way XTerm works.

As for the XTerm extended keyboard modifiers, I haven't look at those before, so I don't know how useful they'd be, but I'd personally like to get the basics sorted out first before starting on anything like that.

Keyboard handling is quite a large area of work, so I wonder if it's worth putting together a spec documenting exactly what we expect the behaviour to be, even if we don't have it all implemented yet. That way users can more easily see if a particular behaviour is deliberate, or a bug, or just not yet done.

[herolover]

ctrl + backspace also doesn't work.

[zadjii-msft]

@herolover That particular keystroke is actually unrelated to this problem - ctrl+bksp actually has a fix in PR over in #3935