rfc: built-in option to request for "extended-keys" aka "CSI u"

[vbauerster]

Upcoming tmux 3.2 has introduced support for extended-keys. Basically it means that CSI u sequences are not automatically enabled inside tmux, unless requested by application by sending special escape sequence.

To enable extended keys application should send \033[>4;1m and to disable \033[>4;0m respectively.

I tried to apply following script with no success.

hook global ModuleLoaded tmux %{
    nop %sh{ printf '\033[>4;1m' }
    hook global KakEnd .* %{
        nop %sh{ printf '\033[>4;0m' }
    }
}

Issuing printf '\033[>4;1m' manually inside tmux and then starting kakoune works.

Probably there is need to have a built-in option for this, as I suppose my script didn't work because there is need to have some kind of direct access to the terminal.

[Screwtapello]

The builtin-terminal-ui branch already sends a special sequence to enable extended-keys mode in Kitty: 89865b7

It's unfortunate that tmux and xterm seem to be using a different enable/disable sequence than Kitty and iTerm. I hope the actual key-encodings are compatible.

[vbauerster]

Is it feasible to add \033[>4;1m variant as well? Or should I ask tmux's maintainer to support kitty style \033[>1u?

[kovidgoyal]

Note that I highly doubt the actual escape codes produced by xterm, iterm and kitty actually are the same for all keys (in particular for shifted variants), though they will be similar for most keys. For details see https://sw.kovidgoyal.net/kitty/keyboard-protocol.html and ongoing discussion in kovidgoyal/kitty#3248

If you have concerns as an application developer, I suggest chiming in on that issue asap. Once kitty 0.20 is released I will be much less willing to make changes to the protocol.

[vbauerster]

Is it feasible to add \033[>4;1m variant as well? Or should I ask tmux's maintainer to support kitty style \033[>1u?

@mawww What do you think?

Maybe it's worth to let user define the on/off sequence, instead of hardcoding in the code?

Following script works unless new window is spawned by :new command. I suppose in new window there is different /dev/tty.

hook global ModuleLoaded tmux %{
    hook global WinCreate .* %{
        nop %sh{ printf '\033[>4;1m' > /dev/tty }
    }
    hook global KakEnd .* %{
        nop %sh{ printf '\033[>4;0m' > /dev/tty }
    }
}

[kovidgoyal]

This should make things easier for you: kovidgoyal/kitty@d360d07

[mawww]

Kakoune will adapt to whatever the terminal landscape ends up being, sending the two sequences if necessary.

It is unfortunate we have those two sequences now, seeing that Kitty now supports the xterm variant we could migrate to it (and ask @gnachman to add support to it in iterm2, although I feel sorry having asked for the kitty variant and now requesting yet another sequence).

Ideally a consensus would form on terminal-wg regarding that sequence and we could use it as guidance, but while that group generates lots of valuable discussion it does not often reach anything close to consensus.

I guess for now we might wait and see, I am really happy to see some progress on that front, thanks again @kovidgoyal for working on that Kitty side.

[Delapouite]

As a reference, related issue in neowim repo: neovim/neovim#14400

[gnachman]

@mawww iTerm2 supports CSI > 4 ; 1 m with the aim of xcode compatibility. I don't think I have enough context here—what change do you need on my side?

[mawww]

@gnachman Thats great, I had opened an issue to support the kitty style CSI > 1 u which you did take care of, then I realized there was this alternate xterm version with CSI > 4 ; 1 m .

Now that kitty and iterm2 support the xterm escape sequence I can migrate Kakoune to just emit that.