Add support for kitty's new, extended keyboard protocol #319
Just thought I'd create an issue for this, since it was mentioned in the IRC channel the other day.
tl;dr: the author of
kitty has just added a new encoding scheme for terminal key codes, based on the old "fixterms" proposal, but with several improvements.
Since most of the issues it aims to fix also affect
foot to some degree, I think it'd be beneficial to implement support for this protocol. From the perspective of someone who spends a lot of time working on TUI apps, it seems to solve all the major problems I've encountered with keyboard handling.
As far as I can tell, the protocol looks sane. It also looks relatively easy to implement - most appears to be possible to do without lookup tables.
I don't have that much experience with developing TUI apps, and don't have much to say about the finer details of the protocol.
@craigbarnes there doesn't appear to be any way for the terminal to tell the application which level of the protocol it supports. Meaning we'd need to implement all of it. Do you see any problems with that?
there doesn't appear to be any way for the terminal to tell the application which level of the protocol it supports. Meaning we'd need to implement all of it. Do you see any problems with that?
I don't think there's any problem with just implementing it all at once. I think all the extra modes exist for a good reason and are a big part of the value it would add.
I see your point about versioning though. If we just link to the kitty docs and say we support it, there could be some lag between different terminals implementing newly added features/modes.
The kitty docs do include the following paragraph:
An application can query the terminal for support of this protocol by sending the escape code querying for the current progressive enhancement status followed by request for the primary device attributes <https://vt100.net/docs/vt510-rm/DA1.html>. If an answer for the device attributes is received without getting back an answer for the progressive enhancement the terminal does not support this protocol.
...but all the usual caveats about async request/response apply.
If we just link to the kitty docs and say we support it, there could be some lag between different terminals implementing newly added features/modes.
As long as the changes are small, I think at least we can be fairly quick in getting a point release out, should it be necessary. As long as we are aware of the change having been made, that is.
Update on this for anyone who may be interested: I'm going to start working on a PR once the kitty implementation becomes "stable" and makes it into a proper release.
Kitty landed this feature in the 0.20.0 release a couple of weeks ago. I think I'm going to implement the client side (in dte) first, to wrap my head around it, and then start working on the terminal side.
I'd like to report that the 1.10.2 release broke shortucts using the alt key in kakoune
I'm posting here rather than opening a new issue because I believe this to be a result of the partial support in 1.10.2.
It is possible that this is more of a bug with kakoune, but kakoune works fine with kitty, so I'd rather have a confirmation the current kitty keyboard protocol implementation in foot shouldn't have broken kakoune.
The first thing to check is which flags kakoune enables. In foot 1.10.2, we only support
If kakoune enables more than that, it is important that kakoune also queries the terminal (with
\e[?u), to see which flags the terminal actually supports, rather than just assuming it supports them all.
If all that checks out, it's time to dig into what sequences kakoune expects, and which ones foot is sending.
Tested briefly: kakoune appears to only enable "disambiguate escape codes" (the first level/mode, the one supported in 1.10.2).
Some alt combos do work, others don't.
For example, Alt+Shift+7 (
a-/) does not work in foot, but does work in kitty. The weird thing is, kitty and foot emits the same escapes for this key combo...
kakoune appears to only enable "disambiguate escape codes" (the first level/mode, the one supported in 1.10.2).
Ah, no, it enables
5, which is "disambiguate" and "report alternate keys". The bug here is that kakoune doesn't check which flags actually got enabled...
Of course, we'll eventually add support for "report alternate keys".
FWIW, all other modes are either already done, or close to done. So we should see this implemented soon.
Btw, #834 is the last kitty kbd PR. It includes all previous work, and adds the final mode, "report alternate key".
People with non-latin layouts are encouraged to try it out. Kakoune is obviously one application that makes use of the protocol. Notcurses is another (I've been using the `notcurses-input' utility for some of my testing).
A more hands-on approach:
echo -e '\e[>31u' && read && read
This will enable all kitty report modes. The double
read is to handle the first read terminating on the Return release event.
Note: your terminal will pretty much be unusable after this. Be prepared to force-close it.
No due date set.
No dependencies set.
Deleting a branch is permanent. Although the deleted branch may exist for a short time before cleaning up, in most cases it CANNOT be undone. Continue?