[dev] [st] Thoughts on kitty keyboard protocol

[Tobias Bengfort]

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

[Markus Wichmann]

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

[Страхиња Радић]

On 21/05/22 06:50, Tobias Bengfort wrote:
> 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?

Speaking as (thus far) just a user of suckless programs and someone who supports
suckless philosophy, it comes down to: why should this protocol be supported?
There isn't a significant number of existing suckless programs that need
supporting this protocol, in fact I think that there are none. It is just a
proposal used by one terminal emulator and not regulated by any of the existing
standards bodies.

As for the terminal emulator kitty which is using it, it does include a number
of unnecessary features. Why would a terminal emulator need OpenGL? Its job is
to just allow terminal I/O. It should work on older hardware, and on systems
where OpenGL isn't or cannot be installed. But it seems to have grown a
following among people who generally like to use complicated software.

As far as the attitude of the developer behind it, I have seen examples of him
locking proposals or bug reports on kitty's Github page when they don't match
his vision, disregarding arguments. It might be irrelevant, but in the
hypothetical case of presenting that protocol to a standards body, maybe not.

[opal hart]

On Sat, 22 May 2021 15:10:02 +0200
Страхиња Радић <con...@strahinja.org> wrote:

> Speaking as (thus far) just a user of suckless programs and someone who supports
> suckless philosophy, it comes down to: why should this protocol be supported?
> There isn't a significant number of existing suckless programs that need
> supporting this protocol

Suckless software isn't a void separate from the rest of the world, and
the "suckless philosophy" is constantly inconsistent with its own
beliefs. Your underlying point that little (if any) software supports
this protocol may be correct though.

> As for the terminal emulator kitty which is using it, it does include a number
> of unnecessary features. Why would a terminal emulator need OpenGL?

Of all the issues I have with kitty, GPU acceleration is not one of
them.

> Its job is to just allow terminal I/O.

And display it.

> It should work on older hardware, and on systems where OpenGL isn't
> or cannot be installed.

There are plenty of other terminal emulators for systems where it would
be impractical to install kitty.

> As far as the attitude of the developer behind it, I have seen examples of him
> locking proposals or bug reports on kitty's Github page when they don't match
> his vision, disregarding arguments. It might be irrelevant, but in the
> hypothetical case of presenting that protocol to a standards body, maybe not.

You're on a mailing list for opinionated software to ... complain about
other opinionated software?

I really hope you understand how poorly you have been arguing. While I
believe it is pointless to support "yet another" set of terminal
control sequences, it's barely for the reasons you gave. And if anyone
does want to support this protocol, it would be better done in an
optional feature patch or a fork.

--
wowaname <https://wowana.me/pgp.xht>

[Hiltjo Posthuma]

On Sun, Jun 20, 2021 at 08:25:23PM +0000, opal hart wrote:
> On Sat, 22 May 2021 15:10:02 +0200
> Страхиња Радић <con...@strahinja.org> wrote:
>
> > Speaking as (thus far) just a user of suckless programs and someone who supports
> > suckless philosophy, it comes down to: why should this protocol be supported?
> > There isn't a significant number of existing suckless programs that need
> > supporting this protocol
>
> Suckless software isn't a void separate from the rest of the world, and
> the "suckless philosophy" is constantly inconsistent with its own
> beliefs. Your underlying point that little (if any) software supports
> this protocol may be correct though.
>

Constantly inconsistent in what way?

> > As for the terminal emulator kitty which is using it, it does include a number
> > of unnecessary features. Why would a terminal emulator need OpenGL?
>
> Of all the issues I have with kitty, GPU acceleration is not one of
> them.
>
> > Its job is to just allow terminal I/O.
>
> And display it.
>
> > It should work on older hardware, and on systems where OpenGL isn't
> > or cannot be installed.
>
> There are plenty of other terminal emulators for systems where it would
> be impractical to install kitty.
>
> > As far as the attitude of the developer behind it, I have seen examples of him
> > locking proposals or bug reports on kitty's Github page when they don't match
> > his vision, disregarding arguments. It might be irrelevant, but in the
> > hypothetical case of presenting that protocol to a standards body, maybe not.
>
> You're on a mailing list for opinionated software to ... complain about
> other opinionated software?
>
> I really hope you understand how poorly you have been arguing. While I
> believe it is pointless to support "yet another" set of terminal
> control sequences, it's barely for the reasons you gave. And if anyone
> does want to support this protocol, it would be better done in an
> optional feature patch or a fork.
>
> --
> wowaname <https://wowana.me/pgp.xht>

--
Kind regards,
Hiltjo

[Страхиња Радић]

On 21/06/20 08:25, opal hart wrote:
> Suckless software isn't a void separate from the rest of the world,

Suckless software is following a specific set of principles, and the software
that sucks is not following those principles. The two are separate.

> and
> the "suckless philosophy" is constantly inconsistent with its own
> beliefs.

I will join Hiltjo in asking for examples.

> Of all the issues I have with kitty, GPU acceleration is not one of
> them.

It doesn't matter what issues you might have. It is an unnecessary feature. A
terminal emulator is not a graphically intensive program like a game. It is
meant to enable terminal I/O.

> And display it.

"O" in "I/O" stands for "output".

> There are plenty of other terminal emulators for systems where it would
> be impractical to install kitty.

Why would they need to support kitty's protocol? If we are speaking about st, it
is a finished program, fulfilling its purpose while not adding unnecessary bloat.

> You're on a mailing list for opinionated software to ... complain about
> other opinionated software?

Not complain, just stating that while most suckless programs tend to respect
standards like POSIX, introducing a protocol which is nonstandard to a standards
body, for example ISO, by someone unwilling to potentially modify that protocol
due to the discussion in the said body would be pointless.

> And if anyone
> does want to support this protocol, it would be better done in an
> optional feature patch or a fork.

I agree. However, that was not what Tobias (the OP) called for. It was rather
the inclusion of the support for kitty protocol in base st.

[Tobias Bengfort]

On 21/06/2021 07.18, Страхиња Радић wrote:
>> And if anyone
>> does want to support this protocol, it would be better done in an
>> optional feature patch or a fork.
>
> I agree. However, that was not what Tobias (the OP) called for. It was rather
> the inclusion of the support for kitty protocol in base st.

That is not exactly what I was asking about: Obviously, backwards
compatibility is *the* major issue with the proposal. It only really
makes sense if it replaces the old protocol at some place. Otherwise it
would just add bloat.

To me it is also obvious that this protocol sucks less than the old one.
Currently you need to write a GUI if you need to get reliable keyboard
events. This proposal would allow you to do the same in a TUI. TUIs
require much less code compared to GUIs.

So my question was: Do you consider this protocol to be so important
that you want to push for its adoption, even though it will lead to more
code in the short term?

From what I read so far this does not seem to be the case though.

tobias

[Страхиња Радић]

On 21/06/21 07:00, Tobias Bengfort wrote:
> To me it is also obvious that this protocol sucks less than the old one.

If we go only by the added code, it is quite the contrary. Less is more.

> Currently you need to write a GUI if you need to get reliable keyboard
> events. This proposal would allow you to do the same in a TUI. TUIs require
> much less code compared to GUIs.

TUIs are still not ideal. What is closer to ideal is CLI. Nonetheless, there are
many core suckless programs which are X programs, and none that I know of which
are TUI (be it using bloated libraries like ncurses, or using simpler solutions
like termbox). Even the IRC client ii is not TUI but CLI.

This protocol seems to cater to TUIs, adding functionality which is as of now
not widely accepted nor widely implemented.