Add support for kitty's new, extended keyboard protocol #319
Labels
No Label
bug
doc
duplicate
easy
enhancement
help wanted
invalid
not-a-bug
performance
question
refactor
regression
upstream
what do you think?
wiki
wontfix
No Milestone
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: dnkl/foot#319
Loading…
Reference in New Issue
There is no content yet.
Delete Branch "%!s(<nil>)"
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?
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
kittyhas 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
footto 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:
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?
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:
...but all the usual caveats about async request/response apply.
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 referenced this issue2021-01-30 10:44:50 +00:00
craigbarnes referenced this issue2021-02-11 07:29:24 +00:00
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.
Sounds like a good plan
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
\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.
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...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.
dnkl referenced this issue2021-12-07 18:56:35 +00:00
Tested very briefly, but #834 appears to fix the kakoune issue.
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:
This will enable all kitty report modes. The double
readis 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.