Should kitty send kitty protocol defined sequences for media keys when the protocol is not in use? #7037
-
|
I've followed kitty protocol when it comes encoding keys that usually don't have a standard escape sequence, but not used to produce other keys. For example However the specification doesn't seem to explicitly say that legacy keys can be encoded that way and for some users it's undesired behavior (for whatever reason). Maybe we should clarify the specification on that matter as well? |
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 1 reply
-
|
IMO, it should. If any particular users dont want a particular key
to generate events, they can remap it to not do so. There can be no
reasonable expectation that pressing some keys has no effect, just
because the legacy encoding did not have an encoding for the key.
It allows, for example, using media (or other non traditional) keys
in zsh via bindkey -s
|
Beta Was this translation helpful? Give feedback.
-
|
Yeah, I also think that there's no need to press random keys and expect that they don't do anything. The thing is that they may confuse application which I think a few resulted in random escape being inserted, though a lot of cli/tui apps don't use real vte parsers. It's also probably kitty is the only terminal sending them without any kitty protocol mode (excluding alacritty). |
Beta Was this translation helpful? Give feedback.
-
|
On Sun, Jan 21, 2024 at 06:18:56PM -0800, Kirill Chibisov wrote:
Yeah, I also think that there's no need to press random keys and expect that they don't do anything. The thing is that they may confuse application which I think a few resulted in random escape being inserted, though a lot of cli/tui apps don't use real vte parsers. It's also probably kitty is the only terminal sending them without any kitty protocol mode (excluding alacritty).
Yes, the con of this is that you can end up with garbage on screen in
your CLI app when you press a key that the app doesn't understand.
The pro is you can use those keys in CLI apps that dont understand the kitty
keyboard protocol, if they can be configured to understand them.
Prominent such apps are zsh and older version of vim before it got
support for the kkp.
The spec currently has this language:
```
Key events that could not be represented in legacy mode are encoded using a CSI u escape code, that most terminal programs should just ignore.
```
To me this implies that terminals should send non-encodeable keys in
legacy mode as CSI u sequences.
However, it's really a judgement call which behavior you prefer. As such I am not
sure the spec should mandate any behavior. Indeed you can possibly make
an option controlling this behavior so users can choose whichever makes
more sense for their use cases.
|
Beta Was this translation helpful? Give feedback.
-
probably adding |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
a9c7a85