Add support for kitty's new, extended keyboard protocol #319

Open
opened 10 months ago by craigbarnes · 6 comments
Collaborator

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.

Links:

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. Links: * https://sw.kovidgoyal.net/kitty/keyboard-protocol.html * https://github.com/kovidgoyal/kitty/issues/3248 [mentioned]: https://freenode.logbot.info/foot-terminal/20210122 ["fixterms"]: http://www.leonerd.org.uk/hacks/fixterms/
craigbarnes added the
enhancement
label 10 months ago
Owner

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?

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?
Poster
Collaborator

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.

> 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](https://sw.kovidgoyal.net/kitty/keyboard-protocol.html#detection-of-support-for-this-protocol) 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.
Owner

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.

> 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.
dnkl added a new dependency 10 months ago
dnkl added this to the 1.7.0 milestone 10 months ago
dnkl removed a dependency 10 months ago
dnkl removed this from the 1.7.0 milestone 10 months ago
Poster
Collaborator

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.

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.
Poster
Collaborator

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.

Kitty landed this feature in the [0.20.0](https://sw.kovidgoyal.net/kitty/changelog.html#id4) release a couple of weeks ago. I think I'm going to implement the client side (in [dte](https://gitlab.com/craigbarnes/dte)) first, to wrap my head around it, and then start working on the terminal side.
Owner

Sounds like a good plan

Sounds like a good plan
dnkl referenced this issue from a commit 1 week ago
dnkl referenced this issue from a commit 2 days ago
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.