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

Closed
opened 2 years ago by craigbarnes · 14 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/ * [x] [Disambiguate escape codes](https://codeberg.org/dnkl/foot/pulls/811) * [x] [Report event types](https://codeberg.org/dnkl/foot/pulls/822) * [x] [Report alternate keys](https://codeberg.org/dnkl/foot/pulls/834) * [x] [Report all keys as escape codes](https://codeberg.org/dnkl/foot/pulls/825) * [x] [Report associated text](https://codeberg.org/dnkl/foot/pulls/833)
craigbarnes added the
enhancement
label 2 years 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 2 years ago
dnkl added this to the 1.7.0 milestone 2 years ago
dnkl removed a dependency 2 years ago
dnkl removed this from the 1.7.0 milestone 2 years 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 year ago
dnkl referenced this issue from a commit 1 year ago

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.

I'd like to report that the 1.10.2 release broke shortucts using the alt key in [kakoune](https://https://kakoune.org/) 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.
Owner

The first thing to check is which flags kakoune enables. In foot 1.10.2, we only support \e[>1u.

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.

The first thing to check is which flags kakoune enables. In foot 1.10.2, we only support `\e[>1u`. 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.
Owner

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

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, <kbd>Alt</kbd>+<kbd>Shift</kbd>+<kbd>7</kbd> (`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...
Owner

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".

> 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".
Owner

FWIW, all other modes are either already done, or close to done. So we should see this implemented soon.

FWIW, all other modes are either already done, or close to done. So we should see this implemented soon.
Owner

Tested very briefly, but #834 appears to fix the kakoune issue.

Tested **very** briefly, but https://codeberg.org/dnkl/foot/pulls/834 appears to fix the kakoune issue.
Owner

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).

Btw, https://codeberg.org/dnkl/foot/pulls/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](https://github.com/dankamongmen/notcurses) is another (I've been using the `notcurses-input' utility for some of my testing).
Owner

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.

A more hands-on approach: ```sh 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 <kbd>Return</kbd> **release** event. Note: your terminal will pretty much be unusable after this. Be prepared to force-close it.
dnkl closed this issue 12 months ago
Sign in to join this conversation.
No Milestone
No Assignees
3 Participants
Notifications
Due Date

No due date set.

Dependencies

No dependencies set.

Reference: dnkl/foot#319
Loading…
There is no content yet.