[RFC] New keyboard reporting protocol #3248
Comments
|
I think there's a tiny typo in the spec. Event types, examples section, release event uses two colons, shouldn't it be semicolon after the key-code? |
|
On Sun, Jan 17, 2021 at 03:11:05AM -0800, msokalski wrote:
I think there's a tiny typo in the spec. Event types, examples section, release event uses two colons, shouldn't it be semicolon after the key-code?
CSI key-code:modifier:3 # this is a release event
No, that is a sub-parameter. Parameters are separated by semi-colons and
sub-parameters by colons. This is for example how, how the CSI for underline styles, work.
|
|
I'm now confused with semicolons for other events, isn't |
|
Oh yeah sorry my mistake, that was indeed a typo, there is semi-colon between key-code and modifier. I misread your previous post. Now fixed. |
|
My keyboard specs: When I'm typing these combinations in terminal I get the following prints: Tested with an empty config file. Is this normal or I'm missing something? The last one I showed is particularly annoying because inside |
|
@browser-bug Can you run kitty as kitty --debug-keyboard and post the output when pressing the problem keys. From your description it looks like those keys are not generating text on your system. |
|
@kovidgoyal Sure thing. Following the order in which I posted. |
|
Should be fixed by my latest commit |
|
@kovidgoyal now |
|
enter and backspace were a typo, now fixed. What does left_ctrl and |
|
@kovidgoyal it was connected to the typo since any combination of L_CTRL/R_CTRL + wasn't sending any command. Now everything works. |
|
I'm signaling others unexpected key combs: |
|
Those are expected, keys that produce no output normally now are encoded |
|
@kovidgoyal I've read through the docs and I'm really liking this proposal so far. It's a huge improvement over the previous protocol, in my opinion, and seems to solve pretty much every problem I've encountered w.r.t. terminal key codes. I'm planning to start working on a patch to add this protocol to the foot terminal in the near future. However, if you'll forgive me for bikeshedding just a little, my only minor criticism would be the event type sub-param:
I agree that sub-params make perfect sense for underline styles (and RGB colors) in I hope this isn't too much of a nitpick, but it was the only thing that struck me as somewhat odd when reading through the docs. Thank you for putting this protocol together and documenting it so well! |
|
On Mon, Jan 25, 2021 at 04:22:56PM -0800, Craig Barnes wrote:
@kovidgoyal I've read through the docs and I'm really liking this proposal so far. It's a huge improvement over the previous protocol, in my opinion, and seems to solve pretty much every problem I've encountered w.r.t. terminal key codes. I'm planning to start working on a patch to add this protocol to the [foot](https://codeberg.org/dnkl/foot) terminal in the near future.
Glad to hear it :)
However, if you'll forgive me for bikeshedding just a little, my only small criticism would be the event type sub-params:
Well, I knew sooner or later someone would :)
> No, that is a sub-parameter. Parameters are separated by semi-colons and sub-parameters by colons. This is for example how, how the CSI for underline styles, work.
I agree that sub-params make perfect sense for underline styles (and RGB colors) in SGR sequences, but I can't really see how they're appropriate for key event types. It seems to me that all 3 params in this case are logically just parameters of the CSI u control function. The event type and the modifier don't seem any more closely related than the key and the modifier are.
The reason sub-parameters are used are:
1) The data belongs together. For instance, the main key code, shifted
key code and alternate key code are all key codes, and therefore are one
parameter with sub-parameters. Text is a sequence of related code points
and so belongs together. Similarly the modifiers and event types
are both things that modify the meaning of a key event, and therefore
belong together. In the last case, I agree it's possible to argue it
either way, but given that the use of sub-parameters is clear cut in the
other two cases, it seemed odder to leave it out in the last case.
2) I find thinking and parsing and generating grouped sets of parameters
easier. Without it it means lots of empty ;;;; sections. It makes the
simplest form of the escape code backwards compatible with the fixterms
proposal and the legacy CSI~ encoding. Without using subparameters, you
would either have to make the first two parameters key code and modifier
or break backwards compatibility. The former means related things are no
longer together, the latter is not desirable for obvious reasons.
|
In practice, I guess most terminals wouldn't emit more than 1 key event as a single sequence, but I see your point.
Yeah, that makes sense from a backwards compatibility perspective. It just seems a little strange to see the event type as a sub-param, but not the modifiers. I don't have a particularly strong opinion either way though. Agreeing on a common protocol with a few minor back compat. artifacts seems a lot better than mindless nitpicking. The rest of the protocol also seems very well thought out, so I'll just trust your judgement and implement it as-is. |
|
Just to be clear you can have only one key event per CSIu escape code. The empty ;;;; sections when not using subgroups are caused by the fact that one there could be data that needs to be encoded in a later field of a single event while earlier fields are empty (default valued). For example, CSI keycode;;shifted-keycode;;u where the empty fields are default valued such as CSI keycode;modifier;shifted-keycode;alternate-keycode;event-type;...u |
|
Gave it a go in Kakoune, almost works out of the box after manually enabling it with I think having an opt-in escape sequence to enable/disable this is the way to go, as shells tend to get confused with Out of curiosity, what is the reason you did not go with the more classic |
|
On Mon, Feb 01, 2021 at 10:22:26PM -0800, Maxime Coste wrote:
Gave it a go in Kakoune, almost works out of the box after manually enabling it with `nop %sh{ printf '\033[>1u' > /dev/tty }`, it did trigger a bug Kakoune side (escape coming in as `CSI 27 u` was not recognized), but it work nicely after fixing that.
Good to hear.
I think having an opt-in escape sequence to enable/disable this is the way to go, as shells tend to get confused with `CSI u` encoding (as I could see when enabling it in the settings on iterm2). I'd be happy to make Kakoune emit `CSI > 1 u` on terminal setup provided this does not confuse other terminals (I'd expect them to ignore it gracefully as its a private sequence).
Non-buggy terminals will ignore it, and given that CSI is the most
common escape sequence it is unlikely many terminal wont at least parse
it correctly. Still you could make it conditional on detecting "kitty"
in TERM, at least to start with, until it is more widepsread.
Out of curiosity, what is the reason you did not go with the more classic `CSI ? <number> h` and `CSI ? <number> l` for enabling disabling ?
It's not a binary on/off. There are various different features you can
enable, see the full spec, beyond the quickstart. Also I want there to
be a stack so an application can easily change modes and restore the
previous mode on exit without needing to query the terminal. So for example if a shell wnts to implement it, it can push the mode it wants onto the stack, and pop it off before running a command, easily.
|
Ah, I see what you mean now. My main concern with the sub-params is that it seems somewhat opaque as to why they're being used, even after reading the documentation. It's also the first time I've seen them used in sequences sent from terminal to client. What do you think about using different final bytes to indicate the different event types (e.g. |
|
On Mon, Feb 01, 2021 at 10:49:18PM -0800, Craig Barnes wrote:
> Just to be clear you can have only one key event per CSIu escape code. The empty ;;;; sections when not using subgroups are caused by the fact that one there could be data that needs to be encoded in a later field of a single event while earlier fields are empty (default valued). For example, CSI keycode;;shifted-keycode;;u where the empty fields are default valued such as CSI keycode;modifier;shifted-keycode;alternate-keycode;event-type;...u
Ah, I see what you mean now. My main concern with the sub-params is that it seems quite opaque as to why they're being used, even after reading the documentation. It's also the first time I've seen them used in sequences sent from terminal to client.
Seemed fairly self evident to me why they are used, but I can add a line
clarifying it if it helps. And since clients can generate
sub-parameters, I dont see how expecting them to parse them is an undue
burden. And note that in the lowest level of progressive enhancement,
which has the maximum backward compatibility and least amount of changes
required from a client, there are no sub parameters, since the only
information reported is key code and modifiers.
What do you think about using different final bytes to indicate the different event types (e.g. `v`=repeat, `w`=release) or, alternatively, using an intermediate byte?
Why? It would no longer be a CSI u code but a random collection of
things and it would use up a lot more of the potential escape code
space. As for an intermediate byte, what's the advantage over a number??
Not to mention that I tend to regard intermediate bytes as changing the
meaning of the escape code, not adding information to it. That is how
intermediate bytes have been used historically.
|
|
Thanks for all your work, should be useful. Continuing from my earlier issue (#3285), I do hope that terminal programs (shells, text editors, etc.) will adopt an intelligent way to respond to the novelties introduced in this protocol. As it stands, I appear to accidentally and frequently trigger key combos (e.g. Ctrl+enter) that result in some garbage being printed, which can be quite disruptive. What would be the best way forward here? Should I, as a user, configure programs (e.g. fish shell) to somehow deal with the novel key combos introduced in this protocol? Or should people "pressure" maintainers of other programs to implement this new protocol, by e.g. opening issues? I would be happy to do the latter. Emacs, for example, could benefit from being capable of handling more key combos, but currently doesn't understand the new protocol at all. |
|
On Thu, Feb 11, 2021 at 08:09:41AM -0800, Rijnder Wever wrote:
Thanks for all your work, should be useful. Continuing from my earlier issue (#3285), I do hope that terminal programs (shells, text editors, etc.) will adopt an intelligent way to respond to the novelties introduced in this protocol. As it stands, I appear to accidentally and frequently trigger key combos (e.g. <kbd>Ctrl+enter</kbd>) that result in some garbage being printed, which can be quite disruptive.
Yes, that's the hope. It's debatable whether I should not generate any
bytes different from traditional terminals in the default mode, that
avoids the occasional accidental keypress generating garbage instead of
being ignored, in non-supporting programs problem. However it means that
any program that wants to use it then has to opt-in, even for things
like ctrl+enter, shift+enter, etc.
It would be nice to get some more opinions on this. Personally, I find
pressing shift+enter the most common accident. Maybe just filter out
shift and ctrl + enter.
What would be the best way forward here? Should I, as a user, configure programs (e.g. fish shell) to somehow deal with the novel key combos introduced in this protocol? Or should people "pressure" maintainers of other programs to implement this new protocol, by e.g. opening issues? I would be happy to do the latter. Emacs, for example, could benefit from being capable of handling more key combos, but currently doesn't understand the new protocol at all.
I think you opening issues informing the maintainers of the existence
of this protocol would be useful. Whether they choose to adopt or ignore
it remains to be seen.
|
|
ctrl+shift+letter isn't working in my OSX machine, I was trying to look at different layouts. here I tried with ctrl+shift+l it actually works with some letters, such as Apparently it matches a Here is for
I have no idea where this is coming from... I think GLFW? It's misleading because the docs say |
|
ctrl+shift is kitty_mod and is used for kitty shortcuts |
|
On Wed, Oct 06, 2021 at 05:00:53AM -0700, msokalski wrote:
@kovidgoyal I think it would be great to maintain list of terminals supporting this protocol `{ name [+link], [version,] full / partial }`.
Probably, bottom of your specification page is a good place for it.
Btw, thanks for making this protocol a real thing!
Yes, I agree, PRs are most welcome. I am afraid I dont have the
time/patience to test terminals myself.
You can run
kitty +kitten show_key -m kitty
inside a terminal you are testing and press keys to see how it responds.
This will test the full extended keyboard mode, with all enhancements.
At the moment I dont think any terminals support the full extended mode.
iTerm has some kind of partial support its not clear what level.
|
@dankamongmen answering for @craigbarnes here; foot-1.8.2 does not implement the kitty kbd protocol. Neither does the recently released 1.9.x. We still intend to implement it, but I don't have a timeline for when it'll be ready. |
|
And apparently iTerm is planning to implement it too: https://gitlab.com/gnachman/iterm2/-/issues/10017 |
|
Some progress on implementing it in foot: https://codeberg.org/dnkl/foot/issues/319 and https://codeberg.org/dnkl/foot/pulls/811 |
awesome! so long as the "report current support" is implemented correctly, Notcurses will pick it up automatically (after attempting to set 11), and not send |
|
@dankamongmen the plan is to add support incrementally. If we initially support "disambiguate escape codes" ( I think that's what you are saying, but just wanted to make sure.... |
yes. Notcurses will use whatever you can offer. i add all possible/known keyboard inputs to my input automaton. right now a
to get the full story |
|
@dnkl i forgot to mention |
|
foot-1.10.3 implements all flags/modes. I.e. we now support the full Kitty keyboard protocol, barring bugs (of which there are obviously zero...) |
appreciate the help flushing out a few bugs from notcurses! i hope |
|
On Wed, Dec 08, 2021 at 10:04:52AM -0800, Daniel Eklöf wrote:
[foot-1.10.3](https://codeberg.org/dnkl/foot/releases/tag/1.10.3) implements all flags/modes. I.e. we now support the full Kitty keyboard protocol, barring bugs (of which there are obviously zero...)
Great news! Thanks for the heads up. I have added a link to foot as an
alternate implementation of the protocol.
3d59e4e
|
|
I am new to this thread but I am facing a problem. Sometimes I press something in my Kitty terminal that makes some of my Reading this thread, I think I have to set Thank you. |
|
thats great that you guys recognized the problem, but how to identify the capability? its not serious to identify it by terminal (name) itself. what is written in https://sw.kovidgoyal.net/kitty/keyboard-protocol/ Quickstart - send so the question - how to identify the capability/availability of the protocol? |
It's right there on the page you linked: https://sw.kovidgoyal.net/kitty/keyboard-protocol/#detection-of-support-for-this-protocol |
ooke.. should be starting point.. will read further ... ooke ive read it.. the review of the proposed keyboard protocol[1] quickstartterminals that ignore
[2] variants, versions, modesa good enhancement is the further generalization:
the number is not important for now, it can be progressive numbers (1,2,3,4..) or a bitmask (1|2|4|8..) to be determined [3] more useful statementsthe response to [4] the keycode input
keydown = 0/1..N, 0=keyup, [1..N]=repeat the 8-bit response mode is recommended, CSI is [5] not introducing more standardsthe underlying X system, the xlib has: here, the [7] back to normal
|
|
My scrolling with ctrl-shift-pageup stops working after I do some things and one of them is that I just run vim in the terminal. Here's 2 versions of 1st is with no problem. I just type Click to expand``` Loading new XKB keymaps Modifier indices alt: 0x3 super: 0x6 hyper: 0xffffffff meta: 0xffffffff numlock: 0x4 shift: 0x0 capslock: 0x1 �[35mon_focus_change�[m: window id: 0x1 focused: 1 �[33mon_key_input�[m: glfw key: 0x0 native_code: 0x0 action: PRESS mods: none text: '' state: 1 updated pre-edit text: '' �[33mon_key_input�[m: glfw key: 0x0 native_code: 0x0 action: PRESS mods: none text: '' state: 1 updated pre-edit text: '' �[31mPress�[m xkb_keycode: 0x21 clean_sym: l composed_sym: l text: l mods: none glfw_key: 108 (l) xkb_key: 108 (l) alternate_key: 112 (p) ↳ to IBUS: keycode: 0x19 keysym: 0x6c (l) mods: none From IBUS: native_key: 0x6c name: l is_release: 0 handled_by_ime: 0 ↳ to application: glfw_keycode: 0x6c (l) keysym: 0x6c (l) action: PRESS mods: none text: l �[33mon_key_input�[m: glfw key: 0x6c native_code: 0x6c action: PRESS mods: none text: 'l' state: 0 sent key as text to child: l �[32mRelease�[m xkb_keycode: 0x21 clean_sym: l mods: none glfw_key: 108 (l) xkb_key: 108 (l) alternate_key: 112 (p) ↳ to IBUS: keycode: 0x19 keysym: 0x6c (l) mods: none From IBUS: native_key: 0x6c name: l is_release: 1 handled_by_ime: 0 ↳ to application: glfw_keycode: 0x6c (l) keysym: 0x6c (l) action: RELEASE mods: none text: �[33mon_key_input�[m: glfw key: 0x6c native_code: 0x6c action: RELEASE mods: none text: '' state: 0 ignoring as keyboard mode does not support encoding this event �[31mPress�[m xkb_keycode: 0x2f clean_sym: s composed_sym: s text: s mods: none glfw_key: 115 (s) xkb_key: 115 (s) alternate_key: 59 (;) ↳ to IBUS: keycode: 0x27 keysym: 0x73 (s) mods: none From IBUS: native_key: 0x73 name: s is_release: 0 handled_by_ime: 0 ↳ to application: glfw_keycode: 0x73 (s) keysym: 0x73 (s) action: PRESS mods: none text: s �[33mon_key_input�[m: glfw key: 0x73 native_code: 0x73 action: PRESS mods: none text: 's' state: 0 sent key as text to child: s �[32mRelease�[m xkb_keycode: 0x2f clean_sym: s mods: none glfw_key: 115 (s) xkb_key: 115 (s) alternate_key: 59 (;) ↳ to IBUS: keycode: 0x27 keysym: 0x73 (s) mods: none From IBUS: native_key: 0x73 name: s is_release: 1 handled_by_ime: 0 ↳ to application: glfw_keycode: 0x73 (s) keysym: 0x73 (s) action: RELEASE mods: none text: �[33mon_key_input�[m: glfw key: 0x73 native_code: 0x73 action: RELEASE mods: none text: '' state: 0 ignoring as keyboard mode does not support encoding this event �[31mPress�[m xkb_keycode: 0x24 clean_sym: Return composed_sym: Return mods: none glfw_key: 57345 (ENTER) xkb_key: 65293 (Return) ↳ to IBUS: keycode: 0x1c keysym: 0xff0d (Return) mods: none From IBUS: native_key: 0xff0d name: 0x0000e001 is_release: 0 handled_by_ime: 0 ↳ to application: glfw_keycode: 0xff0d (－) keysym: 0xe001 (0x0000e001) action: PRESS mods: none text: �[33mon_key_input�[m: glfw key: 0xe001 native_code: 0xff0d action: PRESS mods: none text: '' state: 0 sent encoded key to child: 0xd �[32mRelease�[m xkb_keycode: 0x24 clean_sym: Return mods: none glfw_key: 57345 (ENTER) xkb_key: 65293 (Return) ↳ to IBUS: keycode: 0x1c keysym: 0xff0d (Return) mods: none From IBUS: native_key: 0xff0d name: 0x0000e001 is_release: 1 handled_by_ime: 0 ↳ to application: glfw_keycode: 0xff0d (－) keysym: 0xe001 (0x0000e001) action: RELEASE mods: none text: �[33mon_key_input�[m: glfw key: 0xe001 native_code: 0xff0d action: RELEASE mods: none text: '' state: 0 ignoring as keyboard mode does not support encoding this event �[31mPress�[m xkb_keycode: 0x25 clean_sym: Control_L composed_sym: Control_L mods: none glfw_key: 57442 (LEFT_CONTROL) xkb_key: 65507 (Control_L) ↳ to IBUS: keycode: 0x1d keysym: 0xffe3 (Control_L) mods: none From IBUS: native_key: 0xffe3 name: 0x0000e062 is_release: 0 handled_by_ime: 0 ↳ to application: glfw_keycode: 0xffe3 (￣) keysym: 0xe062 (0x0000e062) action: PRESS mods: none text: �[33mon_key_input�[m: glfw key: 0xe062 native_code: 0xffe3 action: PRESS mods: ctrl text: '' state: 0 ignoring as keyboard mode does not support encoding this event �[31mPress�[m xkb_keycode: 0x32 clean_sym: Shift_L composed_sym: Shift_L mods: ctrl glfw_key: 57441 (LEFT_SHIFT) xkb_key: 65505 (Shift_L) ↳ to IBUS: keycode: 0x2a keysym: 0xffe1 (Shift_L) mods: ctrl From IBUS: native_key: 0xffe1 name: 0x0000e061 is_release: 0 handled_by_ime: 0 ↳ to application: glfw_keycode: 0xffe1 (￡) keysym: 0xe061 (0x0000e061) action: PRESS mods: ctrl text: �[33mon_key_input�[m: glfw key: 0xe061 native_code: 0xffe1 action: PRESS mods: ctrl+shift text: '' state: 0 ignoring as keyboard mode does not support encoding this event �[31mPress�[m xkb_keycode: 0x70 clean_sym: Prior composed_sym: Prior mods: ctrl+shift glfw_key: 57354 (PAGE_UP) xkb_key: 65365 (Prior) ↳ to IBUS: keycode: 0x68 keysym: 0xff55 (Prior) mods: ctrl+shift From IBUS: native_key: 0xff55 name: 0x0000e00a is_release: 0 handled_by_ime: 0 ↳ to application: glfw_keycode: 0xff55 (ｕ) keysym: 0xe00a (0x0000e00a) action: PRESS mods: ctrl+shift text: �[33mon_key_input�[m: glfw key: 0xe00a native_code: 0xff55 action: PRESS mods: ctrl+shift text: '' state: 0 �[35mKeyPress�[m matched action: scroll_page_up, handled as shortcut �[32mRelease�[m xkb_keycode: 0x70 clean_sym: Prior mods: ctrl+shift glfw_key: 57354 (PAGE_UP) xkb_key: 65365 (Prior) ↳ to IBUS: keycode: 0x68 keysym: 0xff55 (Prior) mods: ctrl+shift From IBUS: native_key: 0xff55 name: 0x0000e00a is_release: 1 handled_by_ime: 0 ↳ to application: glfw_keycode: 0xff55 (ｕ) keysym: 0xe00a (0x0000e00a) action: RELEASE mods: ctrl+shift text: �[33mon_key_input�[m: glfw key: 0xe00a native_code: 0xff55 action: RELEASE mods: ctrl+shift text: '' state: 0 ignoring release event for previous press that was handled as shortcut �[32mRelease�[m xkb_keycode: 0x32 clean_sym: Shift_L mods: ctrl+shift glfw_key: 57441 (LEFT_SHIFT) xkb_key: 65505 (Shift_L) ↳ to IBUS: keycode: 0x2a keysym: 0xffe1 (Shift_L) mods: ctrl+shift From IBUS: native_key: 0xffe1 name: 0x0000e061 is_release: 1 handled_by_ime: 0 ↳ to application: glfw_keycode: 0xffe1 (￡) keysym: 0xe061 (0x0000e061) action: RELEASE mods: ctrl+shift text: �[33mon_key_input�[m: glfw key: 0xe061 native_code: 0xffe1 action: RELEASE mods: ctrl text: '' state: 0 ignoring as keyboard mode does not support encoding this event �[32mRelease�[m xkb_keycode: 0x25 clean_sym: Control_L mods: ctrl glfw_key: 57442 (LEFT_CONTROL) xkb_key: 65507 (Control_L) ↳ to IBUS: keycode: 0x1d keysym: 0xffe3 (Control_L) mods: ctrl From IBUS: native_key: 0xffe3 name: 0x0000e062 is_release: 1 handled_by_ime: 0 ↳ to application: glfw_keycode: 0xffe3 (￣) keysym: 0xe062 (0x0000e062) action: RELEASE mods: ctrl text: �[33mon_key_input�[m: glfw key: 0xe062 native_code: 0xffe3 action: RELEASE mods: none text: '' state: 0 ignoring as keyboard mode does not support encoding this event �[31mPress�[m xkb_keycode: 0x28 clean_sym: e composed_sym: e text: e mods: none glfw_key: 101 (e��) xkb_key: 101 (e) alternate_key: 100 (d��) ↳ to IBUS: keycode: 0x20 keysym: 0x65 (e) mods: none From IBUS: native_key: 0x65 name: e is_release: 0 handled_by_ime: 0 ↳ to application: glfw_keycode: 0x65 (e��) keysym: 0x65 (e) action: PRESS mods: none text: e �[33mon_key_input�[m: glfw key: 0x65 native_code: 0x65 action: PRESS mods: none text: 'e' state: 0 sent key as text to child: e �[32mRelease�[m xkb_keycode: 0x28 clean_sym: e mods: none glfw_key: 101 (e��) xkb_key: 101 (e) alternate_key: 100 (d��) ↳ to IBUS: keycode: 0x20 keysym: 0x65 (e) mods: none From IBUS: native_key: 0x65 name: e is_release: 1 handled_by_ime: 0 ↳ to application: glfw_keycode: 0x65 (e��) keysym: 0x65 (e) action: RELEASE mods: none text: �[33mon_key_input�[m: glfw key: 0x65 native_code: 0x65 action: RELEASE mods: none text: '' state: 0 ignoring as keyboard mode does not support encoding this event �[31mPress�[m xkb_keycode: 0x38 clean_sym: x composed_sym: x text: x mods: none glfw_key: 120 (x��) xkb_key: 120 (x) alternate_key: 98 (b��) ↳ to IBUS: keycode: 0x30 keysym: 0x78 (x) mods: none From IBUS: native_key: 0x78 name: x is_release: 0 handled_by_ime: 0 ↳ to application: glfw_keycode: 0x78 (x��) keysym: 0x78 (x) action: PRESS mods: none text: x �[33mon_key_input�[m: glfw key: 0x78 native_code: 0x78 action: PRESS mods: none text: 'x' state: 0 sent key as text to child: x �[32mRelease�[m xkb_keycode: 0x38 clean_sym: x mods: none glfw_key: 120 (x��) xkb_key: 120 (x) alternate_key: 98 (b��) ↳ to IBUS: keycode: 0x30 keysym: 0x78 (x) mods: none From IBUS: native_key: 0x78 name: x is_release: 1 handled_by_ime: 0 ↳ to application: glfw_keycode: 0x78 (x��) keysym: 0x78 (x) action: RELEASE mods: none text: �[33mon_key_input�[m: glfw key: 0x78 native_code: 0x78 action: RELEASE mods: none text: '' state: 0 ignoring as keyboard mode does not support encoding this event �[31mPress�[m xkb_keycode: 0x2a clean_sym: i composed_sym: i text: i mods: none glfw_key: 105 (i��) xkb_key: 105 (i) alternate_key: 103 (g��) ↳ to IBUS: keycode: 0x22 keysym: 0x69 (i) mods: none From IBUS: native_key: 0x69 name: i is_release: 0 handled_by_ime: 0 ↳ to application: glfw_keycode: 0x69 (i��) keysym: 0x69 (i) action: PRESS mods: none text: i �[33mon_key_input�[m: glfw key: 0x69 native_code: 0x69 action: PRESS mods: none text: 'i' state: 0 sent key as text to child: i �[31mPress�[m xkb_keycode: 0x2d clean_sym: t composed_sym: t text: t mods: none glfw_key: 116 (t��) xkb_key: 116 (t) alternate_key: 107 (k��) ↳ to IBUS: keycode: 0x25 keysym: 0x74 (t) mods: none From IBUS: native_key: 0x74 name: t is_release: 0 handled_by_ime: 0 ↳ to application: glfw_keycode: 0x74 (t��) keysym: 0x74 (t) action: PRESS mods: none text: t �[33mon_key_input�[m: glfw key: 0x74 native_code: 0x74 action: PRESS mods: none text: 't' state: 0 sent key as text to child: t �[32mRelease�[m xkb_keycode: 0x2a clean_sym: i mods: none glfw_key: 105 (i��) xkb_key: 105 (i) alternate_key: 103 (g��) ↳ to IBUS: keycode: 0x22 keysym: 0x69 (i) mods: none From IBUS: native_key: 0x69 name: i is_release: 1 handled_by_ime: 0 ↳ to application: glfw_keycode: 0x69 (i��) keysym: 0x69 (i) action: RELEASE mods: none text: �[33mon_key_input�[m: glfw key: 0x69 native_code: 0x69 action: RELEASE mods: none text: '' state: 0 ignoring as keyboard mode does not support encoding this event �[32mRelease�[m xkb_keycode: 0x2d clean_sym: t mods: none glfw_key: 116 (t��) xkb_key: 116 (t) alternate_key: 107 (k��) ↳ to IBUS: keycode: 0x25 keysym: 0x74 (t) mods: none From IBUS: native_key: 0x74 name: t is_release: 1 handled_by_ime: 0 ↳ to application: glfw_keycode: 0x74 (t��) keysym: 0x74 (t) action: RELEASE mods: none text: �[33mon_key_input�[m: glfw key: 0x74 native_code: 0x74 action: RELEASE mods: none text: '' state: 0 ignoring as keyboard mode does not support encoding this event �[31mPress�[m xkb_keycode: 0x24 clean_sym: Return composed_sym: Return mods: none glfw_key: 57345 (ENTER) xkb_key: 65293 (Return) ↳ to IBUS: keycode: 0x1c keysym: 0xff0d (Return) mods: none From IBUS: native_key: 0xff0d name: 0x0000e001 is_release: 0 handled_by_ime: 0 ↳ to application: glfw_keycode: 0xff0d (－) keysym: 0xe001 (0x0000e001) action: PRESS mods: none text: �[33mon_key_input�[m: glfw key: 0xe001 native_code: 0xff0d action: PRESS mods: none text: '' state: 0 sent encoded key to child: 0xd Connecting to IBUS daemon @ unix:path=/home/onla/.cache/ibus/dbus-vDbFmX6D,guid=b4b7b7dea7b3d33a1503b95f6627584d for IME input management �[36mMove�[m x: 694.0 y: 627.0 grabbed: 0 Connected to IBUS daemon for IME input management IBUS: UpdatePreeditText: '' IBUS: UpdatePreeditText: '' IBUS processed native_key: 0x6c release: 0 handled: 0 IBUS processed native_key: 0x6c release: 1 handled: 0 IBUS processed native_key: 0x73 release: 0 handled: 0 IBUS processed native_key: 0x73 release: 1 handled: 0 IBUS processed native_key: 0xff0d release: 0 handled: 0 IBUS processed native_key: 0xff0d release: 1 handled: 0 IBUS processed native_key: 0xffe3 release: 0 handled: 0 IBUS processed native_key: 0xffe1 release: 0 handled: 0 IBUS processed native_key: 0xff55 release: 0 handled: 0 IBUS processed native_key: 0xff55 release: 1 handled: 0 IBUS processed native_key: 0xffe1 release: 1 handled: 0 IBUS processed native_key: 0xffe3 release: 1 handled: 0 IBUS processed native_key: 0x65 release: 0 handled: 0 IBUS processed native_key: 0x65 release: 1 handled: 0 IBUS processed native_key: 0x78 release: 0 handled: 0 IBUS processed native_key: 0x78 release: 1 handled: 0 IBUS processed native_key: 0x69 release: 0 handled: 0 IBUS processed native_key: 0x74 release: 0 handled: 0 IBUS processed native_key: 0x69 release: 1 handled: 0 IBUS processed native_key: 0x74 release: 1 handled: 0 IBUS processed native_key: 0xff0d release: 0 handled: 0 ```2nd is the problem. I just run Click to expand |
|
vim manages its own scrollback, you cannot use terminal scrollback when |
|
Yeah I use that in vim, but I mean once I exit vim, the kitty terminal instance is broken. After having been in a vim then regarding many shortcut keys, one being ctrl-shift-pageup is not working. I can't scroll up in the terminal anymore. Similarly the mouse wheel scroll in a pristine kitty instance scrolls the terminal's buffer, but once I have opened vim and closed it, then the mousewheel scroll acts same as if I press arrow-up/down, meaning it will populate input field with recent items from the input history in that terminal. What I then have to do is exit the terminal and open a new working instance. Then it will again get broken again by opening and closing vim or doing some other action that triggers this. There are other actions too that breaks these shortcut keys, but I haven't yet found exactly what they are. I use ibus anthy and I had to add |
|
That is a bug in your vim. The behavior your describe does not happen |
Thanks. I finally took the time to see what causes this. It seems that if I have |
|
This has nothing to do with kitty. vim has an absolutely bonkers |
Got a solution! I mentioned this on vim's irc channel and someone noted that if you have both |
Since the previous kitty keyboard reporting protocol was not well received, I have implemented a new one. The new proposal is backward compatible by default producing the exact same bytes as traditional terminals. Applications that want to enable more robust key handling can use progressive enhancement to request more sophisticated behavior. Notable features:
The new protocol has been implemented in master and will be in the next kitty release. The spec for the protocol is: https://sw.kovidgoyal.net/kitty/keyboard-protocol.html
The new escape code is based on the proposal in http://www.leonerd.org.uk/hacks/fixterms/ however, it is more general and fixes various bugs in that proposal.
If there are bugs or things I have overlooked, now is the time to point them out. You can test the implementation in kitty (which is mostly complete, barring bugs) by building kitty from master and running
inside kitty, to see how key events are reported with full progressive enhancement.
@msokalski Please check if this meets your game use case
@gnachman I believe iTerm implements some version of fixterms, so you might be interested in the bugs I discovered in that proposal
@leonerd Please look over the list of bugs in fixterms and correct me if I am wrong about anything https://sw.kovidgoyal.net/kitty/keyboard-protocol.html#bugs-in-fixterms
In particular, there is some controversy about how to encode shift+key, for instance should ctrl+shift+a be encoded as CSI 97; 6 or CSI 65; 5 IMO the former is correct. One reports the actual key pressed, not the shifted form of the key. In my spec the shifted form is available as a sub-parameter.
A general note, I will not entertain bike-shedding about the escape code format. Unless there is a serious bug or concern that causes backward incompatibility/inoperability.
The text was updated successfully, but these errors were encountered: