Add support for CSI u bindings

[Patryk27]

Closes #3101¹

The implementation is based on:

• http://www.leonerd.org.uk/hacks/fixterms/
• https://github.com/alexherbo2/alacritty-extended-keys/blob/master/keys.yml
  (there are many similar keybinding-repos for Alacritty, and there's nothing special about this one - just happened to be the first one that I stumbled upon, and I considered worth mentioning it.)

I've checked the keycodes we yield using showkey -a and emacs -nw, and most of them seem to work correctly (and for the rest I've left some comments in the code).

Please lemme know what you think and if my approach is even valid in the first place - terminals are startlingly complicated piece of software 😅

Different approaches

I've also considered implementing the neat thing that Kitty supports, but for my taste it's an investment not worth that much (to give a peek - my adventure with CSI u started mainly because I wanted for terminal Emacs to recognize Ctrl+Enter 🙃).

¹ disclaimer: this pull request doesn't implement support for modifyOtherKeys, but - as discussed - going with CSI u is probably a better solution

[Patryk27]

Also, if this binding-based approach is correct, I'd gladly extend it to more modifiers - I've started with just a few to get a sneak peek.

[chrisduerr]

I doubt a keybinding-based solution to this could ever provide any meaningful solution.

Limiting things to just 0-9/A-Z just isn't sufficient, that barely helps with Ctrl+Shift but that's about it. I don't think it would be in the spirit of the protocol to half-ass it like this.

I'd have to check some other implementations to get some insights on the common limitations/approaches taken, but I doubt they usually define all the bindings manually. That would certainly create a massive matrix of bindings which quickly becomes a problem.

[listx]

Hello, I just wanted to ask a question here because I am interested in native CSI u support for Alacritty.

I'd have to check some other implementations to get some insights on the common limitations/approaches taken, but I doubt they usually define all the bindings manually. That would certainly create a massive matrix of bindings which quickly becomes a problem.

We just want some functionality that converts the recognized keypresses (with or without modifiers) and sends the CSI u-based encodings instead of whatever we're doing today, correct?

The "recognize keypresses with or without modifiers" bit seems to be in around

alacritty/alacritty/src/input.rs

Lines 799 to 807 in ec4dc32

	if self.ctx.config().ui_config.alt_send_esc
	&& *self.ctx.received_count() == 0
	&& self.ctx.modifiers().alt()
	&& utf8_len == 1
	{
	bytes.insert(0, b'\x1b');
	}
	self.ctx.write_to_pty(bytes);

, so it looks like we just need to add an if-block somewhere around there like this:

if csi_u_flag_is_enabled_in_config {
  // encode using CSI u encoding scheme and add/replace into `bytes`
}

[Patryk27]

@listx Hi; I've already checked this approach while trying to implement modifyOtherKeys some time ago, and while CSI u is conceptually a bit simpler than MOK, there - as far as I remember - remained a core issue: what should happen to keystrokes that already are encoded via ANSI - i.e. whether Ctrl+C should be sent as-is, or using CSI.

For instance, Kitty's approach is to have various levels of "what should be sent via CSI": from "some selected keystrokes", up to "everything"; but, if I understand it correctly, it still requires keeping some hard-coded keymap of "for the most basic level of CSI u, we don't encode Ctrl+A, Ctrl+B, ...".

So a tl;dr would be: a flag such as csi_u_flag_is_enabled_in_config would work, but we probably wouldn't like to just encode all of the keystrokes at once, and imho implementing Kitty's approach might be better (but harder, too).

[listx]

@listx Hi; I've already checked this approach while trying to implement modifyOtherKeys some time ago, and while CSI u is conceptually a bit simpler than MOK, there - as far as I remember - remained a core issue: what should happen to keystrokes that already are encoded via ANSI - i.e. whether Ctrl+C should be sent as-is, or using CSI.

It makes sense to send Ctrl+C as-is (i.e., as \x03) to avoid breaking legacy applications. I think CSI u mode only makes sense for sending previously-unencodable combinations, such as all Ctrl+Shift+{A,Z} and Ctrl+Alt+Shift+{A,Z}.

For instance, Kitty's approach is to have various levels of "what should be sent via CSI": from "some selected keystrokes", up to "everything"; but, if I understand it correctly, it still requires keeping some hard-coded keymap of "for the most basic level of CSI u, we don't encode Ctrl+A, Ctrl+B, ...".

So a tl;dr would be: a flag such as csi_u_flag_is_enabled_in_config would work, but we probably wouldn't like to just encode all of the keystrokes at once, and imho implementing Kitty's approach might be better (but harder, too).

Maybe it's cleaner to make csi_u_flag_is_enabled_in_config encoded everything, and then have a separate flag or recommended keybinding settings to opt-out of certain ranges, such as all Ctrl+{A-Z}?

FWIW I've recently overhauled my own keybindings from Alacritty to Tmux to Emacs (all the way up the "stack" so to speak), and I've come to realize that even if Alacritty natively supported CSI u encodings, it may not work correctly with CLI applications higher up the stack. For example, Tmux 3.2a does not distinguish between Ctrl+I and TAB. So even if Alacritty sends the CSI u encoded form for Ctrl+I, from Tmux this will still be indistinguishable from pressing just TAB. I had to get around this problem by making Alacritty send different custom sequence for Ctrl+I, to be parsed in tmux separately.

Anyway, coming back to the issue in this thread: I think Alacritty's system of allowing custom keybindings works so well that it makes native CSI u support almost moot (or, just not worth the effort to implement). It's probably more valuable to populate the wiki with more examples including CSI u encodings. This way those who do want CSI u bindings can just copy-paste some settings to get it to work.

[huyz]

I had to get around this problem by making Alacritty send different custom sequence for Ctrl+I, to be parsed in tmux separately.

@listx I'm a noob to tmux; do you have sample config lines for this tmux parsing to bring back the Ctrl-I sequence?

[listx]

I had to get around this problem by making Alacritty send different custom sequence for Ctrl+I, to be parsed in tmux separately.

@listx I'm a noob to tmux; do you have sample config lines for this tmux parsing to bring back the Ctrl-I sequence?

Sure, have a look at https://github.com/listx/syscfg/blob/ec89be49694f1befeb8a2dedaa46001632e41360/tmux/.tmux.conf#L348.