Closed Canop closed 8 months ago
When enabled, this introduces perceptible delay with function keys (up, down, pgup, pgdn), on Kitty master (https://github.com/kovidgoyal/kitty#commit=4a64f812ad046b4aea023b85a0ce258da2c5572e).
enable_kitty_keyboard: false
removes the delay.
Do you see a bigger delay than for other keys ?
I wonder if I shouldn't change the approach: instead of waiting for the key release, I could could react on key press unless there's a modifier (ctrl, alt, shift, maybe space) key pressed. This would prevent multi-key combinations without modifier key but would be faster for standard keys (including function keys).
I feel all keys have delays. Even when entering verbs, where I think very little processing is happening. My estimate is ~100-200ms.
With the option disabled, I don't feel any delay at all.
100-200ms ? Damn... That's absolutely not the key release problem then. I'll have to try with the last kitty to see if I reproduce.
It should be better now (still no explanation for such a delay, but most combinations are now built on key press).
It works. Now the latency is barely noticable.
I can still feel a tiny bit of it. But it may well be mental. I'd add some timer code between keypress and screen actually updating to verify.
Current blocking problem: I can't manage to get the caret key on wezterm (it works fine on kitty (and of course on terminals without the kitty keyboard extensions)).
There are other problems in wezterm, eg the ':' key. See https://github.com/wez/wezterm/issues/4785 So I prefer to make the support of this protocol opt-in rather than opt-out.
With this PR comes the ability on terminals implementing Kitty keyboard extensions to bind verbs to key combinations which are normally not available on simple ANSI terminals, for example
space-n
,ctrl-enter
,shift-space
,ctrl-alt-a-b-c
, etc.As a lot of things changed in the engine (i.e. in the crokey and termimad libraries), this PR comes also with risks of regressions.