Terminal: 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

[tai]

Ctrl+SPACE also does not seem to go through.
I have { "command": "unbound", "keys": ["ctrl+space"]} in my profiles.json but emacs still does not receive it. Ctrl+space is needed to set mark in editing buffer as a starting point of all kinds of range operations (cut, copy, etc), so it's making emacs (and all tools with emacs-like binding) impossible to use.

In emacs, you can do "C-q " to show raw input emacs is seeing for a input. Compared with cmder terminal (terminal I'm now using), doing "C-q C-space" yielded "^@" on emacs-on-cmder, whereas emacs-on-WIndowsTerminal yielded nothing.

[smonff]

Ctrl+SPACE also does not seem to go through.
Ctrl+space is needed to set mark in editing buffer as a starting point of all kinds of range operations (cut, copy, etc), so it's making emacs (and all tools with emacs-like binding) impossible to use.

As a workaround, you can use M-x set-mark-command.

[tai]

Okay, it might not be "impossible", but requiring M-x function for every range operation makes Emacs almost useless - that's not a realistic alternative. Breaking CTRL+key combination here and there is a dealbreaker for apps with Emacs and Emacs-like key binding which heavily uses such key combination.