Support for modifyOtherKeys and the "fixterms" protocol

[hovsater]

While Kitty's keyboard protocol is far superior, it only works if the underlying program has support for it. To date, there's just a handful of applications that do:

• The foot terminal
• The WezTerm terminal
• The notcurses library
• The crossterm library
• The Vim text editor
• The Emacs text editor via the kkp package
• The Neovim text editor
• The kakoune text editor
• The dte text editor
• The Helix text editor
• The far2l file manager
• The awrit web browser

tmux does not. It does however support modifyOtherKeys (XTerm's CSI 27 ~ encoding) and the fixterms proposal (which Kitty's keyboard protocol was based upon) through the option extended keys. tmux listens for the XTerm specific sequences CSI > 4; 1 m and CSI > 4; 0 m to toggle extended keys, and accept both modifyOtherKeys sequences and fixterm sequences as input, but only output the latter. Quoting their changelog:

Add support for extended keys - both xterm(1)'s CSI 27 ~ sequence and the libtickit CSI u sequence are accepted; only the latter is output. tmux will only attempt to use these if the extended-keys option is on and it can detect that the terminal outside supports them (or is told it does with the "extkeys" terminal feature).

I'm not entirely sure what the best course of action is here. While Kitty's keyboard protocol is superior, it's not as widespread as XTerm's CSI 27 ~ encoding, so adding support for it makes sense. However, that alone does not allow all modifiers to be mapped, for that we'd need fixterms proposal which I believe is backwards compatible if implemented correctly.

See also

• https://invisible-island.net/xterm/ctlseqs/ctlseqs.html

[mitchellh]

Progress report: I've implemented the modifyOtherKeys setting in the kitty-keys branch. Using dte-K it appears to be working. There are still critical missing features such as the ability for the program to query modify key state which appears to frequently be used to verify the terminal emulator supports it.

I have much more to do in that branch, I plan to take on CSI u and also the full kitty keyboard protocol as well. But if you want to give it a shot early and report back let me know. I have a feeling things may not work without the query support mentioned in the previous paragraph though.

[mitchellh]

I'm going to reopen this for a couple reasons.

1. @hovsater I'd love for you to validate the state of my modifyOtherKeys implementation. I mostly mashed keys into dte -K and kitty +show_key -m legacy. I also compared and based my work on other terminals (mainly Foot). So I hope its okay, but please verify. I would not be surprised if certain sequences are missing.

2. I didn't implement fixterms at all. But I view that as a component of the Kitty keyboard protocol more than it is a component of modifyOtherKeys. I moved the Kitty keyboard protocol to a dedicated issue implement Kitty keyboard protocol #283 to track that and I'd like to keep this thread focused on modifyOtherKeys.

[hovsater]

@mitchellh I just took this for a spin. It's mostly working now! 🎉 The only thing I've noticed so far, is C-S-h not registering as expected. Instead, it seems to emit C-h. I use C-S-h to format my code, so I noticed this right away.

[mitchellh]

@mitchellh I just took this for a spin. It's mostly working now! 🎉 The only thing I've noticed so far, is C-S-h not registering as expected. Instead, it seems to emit C-h. I use C-S-h to format my code, so I noticed this right away.

Poking around various terminals on Mac and Linux, it appears C-S-h requires #283. The rest is good news! I'll close this then...

[mitchellh]

[mitchellh]

@hovsater OKAY! I've consulted the source, i.e. xterm. None of the other reference material was illuminating and there is so much conflicting implementation out there and so very few terminals actually support modifyOtherKeys. I believe I've figured it out.

I believe that C-S-h is only supported via modifyOtherKeys state 2. iTerm emits it for state 1 but I think this is a mistake and I can't get any other terminal to do it, including xterm.

Here is my test script on Linux:

#!/usr/bin/env bash
printf "\x1b[>4;1m" # change to "2" for state 2
showkey -a

With state 1, I couldn't get any terminal to output anything for C-S-h. **But with state 2, xterm outputs: ** CSI 27;6;72~. One thing to note is 72 is H (uppercase), so in even this case, iTerm appears to be sending the wrong code or dte -K is outputting the wrong case (less likely I think).

When I launch dte (the full editor), it only requests modifyOtherKeys state 1. So, with only modifyOtherKeys support, it shouldn't get access to C-S-h.

Note that I couldn't get any terminal on macOS to show the same sequences as xterm under any circumstance. I also cracked open the xterm source and I only eyeballed it but I believe this is not sending the sequences under state 1: https://sourcegraph.com/github.com/ThomasDickey/xterm-snapshots@c2b36af8d216926b8931c6f9cebefd69228e437c/-/blob/input.c?L579

I could be very wrong, I'm not confident. Every implementation (and there are only few) seems different and the behaviors are not consistent at all. Hence, I'm falling back to xterm, but even then I could be reading the source wrong. But when I ran xterm manually I could only get C-S-h to show up in state 2.