Support the kitty keyboard protocol

[xiaq]

What new feature should Elvish have?

https://sw.kovidgoyal.net/kitty/keyboard-protocol/

Two things to figure out:

• Are the enabling and disabling sequences (CSI > 1 u and CSI < u) no-ops for terminals that don't support the protocol
• Is Kitty's encoding completely compatible existing encodings Elvish supports (either there's no overlap, or the overlapped sequences correspond to identical keys)

If both are true, this support can be enabled unconditionally; otherwise it will have to depend on whether the terminal supports the protocol

Output of "elvish -version"

0.21.0-dev.0.20240430145458-c7d81b20a010

Code of Conduct

• [X] I agree to follow Elvish's Code of Conduct.

[hanche]

Regardless, a good first step might be to implement the parsing of the simplest “CSI u“ sequences. That is,

CSI ⟨codepoint⟩ ; ⟨modifiers⟩ u

These can be parsed unconditionally, without fear of incompatibility, since AFAICT no terminal will issue such a sequence with a different meaning. It makes sense to limit support to the modifiers elvish currently knows about (Ctrl, Alt, Shift).

I'd be very suprised if there are any conflict between sequences known to elvish and the ones used by the kitty protocol, but I'll have a look.

Regarding CSI > 1 u and CSI < u, my immediate guess is that they are no-ops in terminals that don't support the protocol. But since we can't possibly test every terminal, I propose adding a boolean variable to the edit: module. Turn it on to enable, off to disable these sequences. The default can be off (unless elvish sees definite evidence that it's safe to turn it on), and the shell can check the variable each time a new command line edit cycle start.

To repeat myself, the parsing of “CSI u” can be done unconditionally, without consulting the variable.