On Sat, May 22, 2021 at 06:50:51AM +0000, Tobias Bengfort wrote: > I just found out about this protocol: > > https://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