Post by Tobias Bengforthttps://sw.kovidgoyal.net/kitty/keyboard-protocol.html
Basically it provides a way to send unambigous esc and other keys as well as
key release events to terminal programs while being mostly backwards
compatible.
It sounds like a reasonable proposal to me. What do you make of it? Should
this be implemented in st?
tobias
Independent of the content of the proposal, I already see that it is
going to be a hard sell to people looking to reduce the amount of code
they have to trust. This new way of sending key events to terminal
applications will require support from terminal emulators and TUI
applications alike. Meaning a new mode for st to send keycodes the new
way, and a new mode for vim/mutt/zsh/... to read those. In the interest
of compatibility (and if I've learned anything about the computer
industry, then that compatibility is the name of the game), the old
modes would need to remain available. So now we end up with useless code
in the applications we have to trust, for we are either not using the
old or the new way. And that tends to lead to code rot one way or
another.
The proposal is indeed not really backwards compatible, it merely
includes a legacy mode that can be turned off. The new mode is entirely
bespoke and would require a significant reworking of most applications.
Now, if the applications were well written, the input system would be
entirely encapsulated from the rest of the application. However, I have
seen reality recently, and it does not look like that. In all
probability, adding a completely new input decoding mechanism (and
abstracting away the differences between the old and new ways) is going
to be significant work.
Next problem is going to be user acceptance. This is entirely
inter-process communication we are talking about here (terminal emulator
<-> TUI application). Ideally the user would not notice. However, the
current way of doing things appears to be "good enough". Most TUI users
know enough about terminals to avoid pressing too many buttons after
hitting <ESC>, due to the ambiguous way the current encoding works. In
practice, it is not a big issue for many. If you now add the likely
possibility of bugs in early rollouts of the new protocol, it will be a
hard sell for most TUI users as well. The current way is working well
enough.
The proposal itselfs seems sound to my untrained eyes, but for the above
reasons, I fail to see how an implementation of that protocol in
addition to the escape sequences already implemented will accomplish
anything useful. Of all the goals given at the top of the linked page,
only number 5 looks really enticing to me, but I am not willing to spend
the effort to fix what is a mild annoyance at most.
Ciao,
Markus