Support CSI {key} u keys without modifiers#11364
Closed
trygveaa wants to merge 1 commit into
Closed
Conversation
The kitty terminal emulator, as well as some others, suppors sending
keys as `CSI {key} u`, like the keys with modifiers that's already
supported, but for keys without any modifiers. The most notable example
is escape being sent as `CSI 27 u`, to be able to distinguish the key
press from the start of an escape sequence. It's also used to support
some "special" keys, like media keys and print screen.
The main reason for adding support for this is a problem with kitty and
the existing key handling in vim. By default kitty has support for keys
that are not traditionally supported in terminals, like super+<key>, and
sends those as keys with modifiers. E.g. super+q is `CSI 113 ; 9 u`. If
I press such a key, vim sets `seenModifyOtherKeys` to true and stops
processing normal control keys, so the bindings i have for those stops
working because kitty sends them as normal control keys by default.
I can set kitty to send control keys as keys with modifiers by enabling
disambiguate escape codes by sending `CSI > 1 u`. This makes the control
keys work again. However, this also changes the escape key to be sent as
`CSI 27 u`, so that stops working. By adding support for this, all keys
work as far as I know.
The problem exists by default when I'm not enabling disambiguate escape
codes though, so it would be nice if vim could enable this
automatically. I think it should be safe to send it to any terminal
emulator, but alternatively vim could query for support of the protocol
by sending `CSI ? u` and check if it gets a reply like `CSI ? flags u`.
Note that none of the escape sequences I wrote actually contains spaces,
they were just added for readability.
You can read more about the keyboard handling in kitty here:
https://sw.kovidgoyal.net/kitty/keyboard-protocol/
There's also an issue in kitty's repo with some discussion here:
kovidgoyal/kitty#4075
Codecov Report
@@ Coverage Diff @@
## master #11364 +/- ##
==========================================
- Coverage 81.87% 81.86% -0.02%
==========================================
Files 162 162
Lines 189326 189337 +11
Branches 43064 43065 +1
==========================================
- Hits 155014 155003 -11
- Misses 21769 21783 +14
- Partials 12543 12551 +8
Flags with carried forward coverage won't be shown. Click here to find out more.
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
Contributor
Author
Do you have any tips on how to do this? I guess the easiest would be to add |
Contributor
|
Trygve Aaberge wrote:
First of all, your patch most likely works fine and it looks like it
won't cause trouble for other terminals.
I will use the code from handle_key_with_modifier() to put the key in
the buffer, it requires special handling in some cases and it's good to
handle multi-byte codes (not sure if anyone sends these, but then
sending Esc this way wasn't expected either).
The kitty terminal emulator, as well as some others, suppors sending
keys as `CSI {key} u`, like the keys with modifiers that's already
supported, but for keys without any modifiers. The most notable
example is escape being sent as `CSI 27 u`, to be able to distinguish
the key press from the start of an escape sequence. It's also used to
support some "special" keys, like media keys and print screen.
There appears to be no reason for this, it's just a bad kitty.
The main reason for adding support for this is a problem with kitty
and the existing key handling in vim. By default kitty has support for
keys that are not traditionally supported in terminals, like
super+<key>, and sends those as keys with modifiers. E.g. super+q is
`CSI 113 ; 9 u`. If I press such a key, vim sets `seenModifyOtherKeys`
to true and stops processing normal control keys, so the bindings i
have for those stops working because kitty sends them as normal
control keys by default.
Again, bad kitty. This is not how it is supposed to work.
I can set kitty to send control keys as keys with modifiers by
enabling disambiguate escape codes by sending `CSI > 1 u`. This makes
the control keys work again. However, this also changes the escape key
to be sent as `CSI 27 u`, so that stops working. By adding support for
this, all keys work as far as I know.
Be very careful with sending that code, because if you send it to other
terminals you will completely break key handling with modifiers. For
some unknown reason Kitty decided to go their own way and use "1"
instead of "2".
The problem exists by default when I'm not enabling disambiguate
escape codes though, so it would be nice if vim could enable this
automatically. I think it should be safe to send it to any terminal
emulator, but alternatively vim could query for support of the
protocol by sending `CSI ? u` and check if it gets a reply like `CSI ?
flags u`.
It is NOT safe to send "CSI > 1 u", because it puts some terminals in a
bad state, where Vim cannot recognize keys with modifiers. This was
noticed by terminal emulators a bit later, which is when "CSI > 2 u" was
added, which does work.
Note that none of the escape sequences I wrote actually contains
spaces, they were just added for readability.
You can read more about the keyboard handling in kitty here: https://sw.kovidgoyal.net/kitty/keyboard-protocol/
There's also an issue in kitty's repo with some discussion here: kovidgoyal/kitty#4075
This reads as "we did this change and now it doesn't work in Vim". "Oh,
must be Vim's problem". Instead of realising that the problem is the
change in Kitty... They don't even try to behave like a good kitty.
…--
TALL KNIGHT: We are now no longer the Knights Who Say Ni!
ONE KNIGHT: Ni!
OTHERS: Sh!
ONE KNIGHT: (whispers) Sorry.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
|
Contributor
|
> The problem exists by default when I'm not enabling disambiguate
> escape codes though, so it would be nice if vim could enable this
> automatically. I think it should be safe to send it to any terminal
> emulator, but alternatively vim could query for support of the
> protocol by sending `CSI ? u` and check if it gets a reply like `CSI
> ? flags u`.
Do you have any tips on how to do this? I guess the easiest would be
to add `CSI > 1 u` to `t_TI` and `CSI < u` to `t_TE`, but I'm not sure
if that's okay/the right thing to do?
It will probably cause problems if the terminal is not Kitty, you can't
predict what will happen when sending some random escape code to a
random terminal.
Does Kitty send a specific termresponse? We do not appear to check for
that. It might not be enough, because it appears there are multiple
verisons of Kitty that behave in different ways.
If we know it's Kitty then perhaps something like what happens with
rbm_status could be used. Note that this is far from ideal, because
there is a delay before we get the result and something may already have
happened (e.g. starting a shell command). It's better to not do this
unless it's really needed.
…--
TALL KNIGHT: Firstly. You must get us another shrubbery!
OTHER KNIGHTS: More shrubberies! More shrubberies for the ex-Knights of Ni!
ARTHUR: Not another shrubbery -
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
|
Contributor
Author
Thanks for merging and fixing that!
Isn't the reason to distinguish between the escape key and escape sequences, and to support more keys? Anyways, I'm not one to say what is correct or not to do.
What For the terminal emulators that don't support this keyboard protocol, won't
Are you mixing
Yes, if you send |
Contributor
Author
|
Here's how neovim is querying this btw, if that's at all helpful: neovim/neovim#18181 Btw, the terminal emulators foot and wezterm also implement this protocol, though they don't send CSI u sequences until you enable it with |
Contributor
|
> There appears to be no reason for this, it's just a bad kitty.
Isn't the reason to distinguish between the escape key and escape
sequences, and to support more keys? Anyways, I'm not one to say what
is correct or not to do.
It doesn't help, any program will still accept Esc as the escape key.
Unless it has a special "kitty mode" perhaps, which defeats the idea to
be able to work with any terminal without hard coding it.
> Be very careful with sending that code, because if you send it to
> other terminals you will completely break key handling with
> modifiers. For some unknown reason Kitty decided to go their own way
> and use "1" instead of "2".
> It is NOT safe to send "CSI > 1 u", because it puts some terminals
> in a bad state, where Vim cannot recognize keys with modifiers.
What `2` are you talking about? Do you mean the sequence vim has for
`t_TI`, `CSI > 4 ; 2 m`? This is not the same, it's a different
sequence (ends in `m` instead of `u`). `CSI > flags u` is a sequence
to enable kittys keyboard protocol, where `flags` is a bit-flag number
indicating what to enable from the list on
https://sw.kovidgoyal.net/kitty/keyboard-protocol/#progressive-enhancement.
`1` is to enable disambiguate escape codes, which is what's relevant
here.
Yes, I dropped some characters there. I don't know what "kitty keyboard
protocol" is. I don't think the value has a name, in the xterm manual
it just says "When modifyOtherKeys is set to 1" and "When
modifyOtherKeys is set to 2". Only the value 2 works.
For the terminal emulators that don't support this keyboard protocol,
won't `CSI > 1 u` just be an unknown CSI sequence? And as far as I
know, unknown CSI sequences are ignored and doesn't do anything?
Perhaps. Some terminals may display something, we have seen this
problem before.
> This was noticed by terminal emulators a bit later, which is when
> "CSI > 2 u" was added, which does work.
Are you mixing `CSI > 2 u` and `CSI > 4 ; 2 m`, or are there any
terminal emulators that has `CSI > 2 u` doing something other than
kitty?
I was talking about "CSI > 4 ; 2 m".
> Does Kitty send a specific termresponse? We do not appear to check
> for that. It might not be enough, because it appears there are
> multiple verisons of Kitty that behave in different ways.
Yes, if you send `CSI ? u`, kitty responds with `CSI ? flags u`, where
`flags` is a number indicating what enhancements are enabled,
corresponding to the `flags` parameter you send when enabling it. Here
is a list of the enhancements:
https://sw.kovidgoyal.net/kitty/keyboard-protocol/#progressive-enhancement
That is not what I mean, t_RV is normally set to "Esc [ > c". On nearly
all "advanced" terminals it returns a version string, where the version
can be used to guess the type of terminal. This is done in
handle_version_response(). It's mainly a cludge to handle users setting
$TERM to something containing "xterm" even though it is really not an
xterm. You can tell them a thousand times that they shouldn't do that,
but it happens anyway.
…--
TIM: Too late.
ARTHUR: What?
TIM: There he is!
[They all turn, and see a large white RABBIT lollop a few yards out of the
cave. Accompanied by terrifying chord and jarring metallic monster noise.]
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
|
Contributor
|
Here's how neovim is querying this btw, if that's at all helpful: neovim/neovim#18181
Btw, the terminal emulators foot and wezterm also implement this
protocol, though they don't send CSI u sequences until you enable it
with `CSI > 1 u`, so they didn't trigger this issue unless you enabled
that yourself. And I see that wezterm actually sends `CSI 27 ; 1 u`
for escape, so it was still working with it enabled.
Great, let's have a dozen more terminal emulators that all work in
slightly different ways...
…--
Save the plankton - eat a whale.
/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
|
Contributor
|
> > Does Kitty send a specific termresponse? We do not appear to check
> > for that. It might not be enough, because it appears there are
> > multiple verisons of Kitty that behave in different ways.
>
> Yes, if you send `CSI ? u`, kitty responds with `CSI ? flags u`, where
> `flags` is a number indicating what enhancements are enabled,
> corresponding to the `flags` parameter you send when enabling it. Here
> is a list of the enhancements:
> https://sw.kovidgoyal.net/kitty/keyboard-protocol/#progressive-enhancement
That is not what I mean, t_RV is normally set to "Esc [ > c". On nearly
all "advanced" terminals it returns a version string, where the version
can be used to guess the type of terminal. This is done in
handle_version_response(). It's mainly a cludge to handle users setting
$TERM to something containing "xterm" even though it is really not an
xterm. You can tell them a thousand times that they shouldn't do that,
but it happens anyway.
I tried it myself. Kitty seems to default $TERM to "xterm-kitty".
Since this contains "xterm" Vim will sent the t_RV sequence.
What comes back is "Esc [ > 1;4000;21c". I don't know what other
versions of Kitty send, thus can't be sure how to recognize a kitty
from that.
…--
If "R" is Reverse, how come "D" is FORWARD?
/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
|
This is what Kitty is trying to solve with its keyboard protocol. It's 2022 and the modifier situation still sucks hard. The kitty protocol was invented to fix the suck once and for all, in hopes that it will gradually be adopted by various console programs and terminal emulators.
It's in one of the links in an earlier comment, IIUC. |
Contributor
Contributor
Author
So as I understand it, a program can send
Correct, this one: https://sw.kovidgoyal.net/kitty/keyboard-protocol/
Well, yes, having many standards is impractical, but it's also sort of the only way to fix the issues with the existing ones I think.
I don't think you should check if the terminal is kitty and do specific things based on that. That wouldn't allow other terminal emulators to implement the keyboard protocol. It would be better to check specifically for the keyboard protocol. This can be done by sending If you get a response that it's supported, you send |
Contributor
|
> It doesn't help, any program will still accept Esc as the escape
> key. Unless it has a special "kitty mode" perhaps, which defeats the
> idea to be able to work with any terminal without hard coding it.
So as I understand it, a program can send `CSI > 1 u` to enable the
protocol and then `CSI ? u` to check if it's enabled. If it receives
`CSI ? 1 u`, it knows that the keyboard protocol is enabled and escape
will be sent as `CSI 27 u` (or `CSI 27 ; 1 u`) and never as `\e`, so
it knows that any `\e` that appears is the start of an escape sequence
and not the escape key. This is a protocol meant to be supported in
multiple terminal emulators (three support it as of now), so you don't
need to hard code each terminal.
First we would need to know when to send that code to enable this
protocol. Letting the user tweak their setup is not a good plan.
I don't think we need to change anything for Esc handling. The current
code has some tricks to handle a single Esc. When the Esc arrives as an
escape sequence then everything works as before. Not using the single-Esc
handling doesn't have any advantage, it just won't be used.
>> This is what Kitty is trying to solve with its keyboard protocol.
>> It's 2022 and the modifier situation still sucks hard. The kitty
>> protocol was invented to fix the suck once and for all, in hopes
>> that it will gradually be adopted by various console programs and
>> terminal emulators.
>
> https://xkcd.com/927/
Well, yes, having many standards is impractical, but it's also sort of
the only way to fix the issues with the existing ones I think.
Why not implement modifyOtherKeys? That's what xterm supports and it's
working fine already. I have not yet seen a reason why yet another
protocol is going to save the world. The Kitty docs mention some
reasons that are irrelevant for Vim.
> That is not what I mean, t_RV is normally set to "Esc [ > c". On
> nearly all "advanced" terminals it returns a version string, where
> the version can be used to guess the type of terminal. This is done
> in handle_version_response(). It's mainly a cludge to handle users
> setting $TERM to something containing "xterm" even though it is
> really not an xterm. You can tell them a thousand times that they
> shouldn't do that, but it happens anyway.
>
> I tried it myself. Kitty seems to default $TERM to "xterm-kitty".
> Since this contains "xterm" Vim will sent the t_RV sequence. What
> comes back is "Esc [ > 1;4000;21c". I don't know what other versions
> of Kitty send, thus can't be sure how to recognize a kitty from
> that.
I don't think you should check if the terminal is kitty and do
specific things based on that. That wouldn't allow other terminal
emulators to implement the keyboard protocol. It would be better to
check specifically for the keyboard protocol. This can be done by
sending `CSI ? u` and check if you get `CSI ? <flags> u` back. I see
that neovim queries with `CSI ? u CSI c`. I think this is because
other terminals implement `CSI c`, so you know that when you get the
response for that you should also have gotten the response for `CSI ?
u` if it's implemented, so you know it's not implemented if you
haven't gotten a response (instead of waiting for a response with a
timeout).
If you get a response that it's supported, you send `CSI > 1 u` to
enable it, and `CSI < u` when vim exits to disable it.
First of all there is the risc that this code shows up on terminals. We
have had the same problem with the cursor position report.
I actually noticed Kitty gave an error message for one of the requests
we send.
Also, this seems like a terminal property that should be in
terminfo/termcap, not something that requires an async check.
For modifyOtherKeys we can detect whether it is working. We could do it
for this one, but I wonder if it makes any difference in what we do with
the keys. It is important that everything goes back to normal when
exiting or when executing a shell command. I suppose if a user does
change t_TI and t_TE it would just work.
…--
I wonder, do vegetarians eat fruit bats?
/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
|
Contributor
Author
Wouldn't it make sense to send it when the application starts?
Yes, I agree that the Esc handling in vim doesn't need to be changed. It was just an example of how the protocol can be used for proper separation of the key and control sequences, which can be an issue in some programs. For instance tmux waits 500ms by default after an escape character to determine if it's the key or a control sequence.
I suppose that's a good question. The reason I went here to vim is that the problem I have is that mappings I have with keys using ctrl in vim stops working after some keys are pressed (because
Hm, not sure about this. @kovidgoyal: Maybe you have some input here?
If you send
Yes, so now with this patch in, I can set it and get it working properly for me at least. It would be nicer if kitty and vim worked well together out of the box though. |
|
On Sat, Oct 15, 2022 at 03:10:01PM -0700, Trygve Aaberge wrote:
> First we would need to know when to send that code to enable this protocol. Letting the user tweak their setup is not a good plan.
Wouldn't it make sense to send it when the application starts?
> I don't think we need to change anything for Esc handling. The current code has some tricks to handle a single Esc. When the Esc arrives as an escape sequence then everything works as before. Not using the single-Esc handling doesn't have any advantage, it just won't be used.
It definitely does. There is no magic trick possible that can distinguish
between a single esc and the start of an escape sequence. You have to wait,
thereby injecting latency into handling of esc key presses. See your own :help ttimeoutlen
Once you move to a properly designed keyboard escape protocol you no
longer need to wait, since *all* key presses are full escape sequences,
so a single esc byte is never an esc key press.
Yes, I agree that the Esc handling in vim doesn't need to be changed. It was just an example of how the protocol can be used for proper separation of the key and control sequences, which can be an issue in some programs. For instance tmux waits 500ms by default after an escape character to determine if it's the key or a control sequence.
> Why not implement modifyOtherKeys? That's what xterm supports and it's working fine already. I have not yet seen a reason why yet another protocol is going to save the world. The Kitty docs mention some reasons that are irrelevant for Vim.
because modifyOtherKeys is badly designed and doesn't solve the entire
problem space. Are you really suggesting that because you are happy with
modifyOtherKeys everybody else should be as well? I'll just point out
that modern terminal editors are all adding support for it: nvim,
kakoune, dte, etc.
I suppose that's a good question. The reason I went here to vim is that the problem I have is that mappings I have with keys using ctrl in vim stops working after some keys are pressed (because `seenModifyOtherKeys` is set to true), so it seemed most natural to change vim. And the most straightforward way to fix this seemed to be to get vim to accept CSI u keys without modifiers and enable the kitty keyboard protocol.
> First of all there is the risc that this code shows up on terminals. We have had the same problem with the cursor position report. I actually noticed Kitty gave an error message for one of the requests we send. Also, this seems like a terminal property that should be in terminfo/termcap, not something that requires an async check.
terminfo is tied to the limitations of ncurses and xterm. It
took Thomas Dickey a decade to add support for truecolor to ncurses. It
cant be relied upon for any modern terminal features.
The kitty keyboard protocol can be detected at runtime without
depending on the value of TERM which is often wrongly set by users and is what terminfo
uses to key its database:
https://sw.kovidgoyal.net/kitty/keyboard-protocol/#detection-of-support-for-this-protocol
IIRC vim already queries the terminal emulator to detect various things, add
the above to that query as well. I don't know of any terminal emulator
that misbehaves when you send it CSI ? u if you do a citation would be
most welcome.
|
Contributor
|
> First we would need to know when to send that code to enable this
> protocol. Letting the user tweak their setup is not a good plan.
Wouldn't it make sense to send it when the application starts?
That is what we do for xterm, the termcap entry in t_TI and t_TE are by
default setup to enable modifyOtherKeys. It took some work to avoid the
negative side effects. It was worth the work, since xterm is used a lot
and other terminals (try to) behave like xterm.
I'm not sure about this new protocol. The escape sequence might not be
handled properly by some terminals (we have seen this before). And once
enabled, what side effects can we expect (for any kind of terminal)?
Since I don't think kitty is widely used, mainly by a group of
enthousiasts, it would be better to restrict enabling the protocol to
terminals where it is supposed to work.
I assume this protocol wasn't implemented all at once, and there must
have been bugfixes. Thus perhaps we should only use it for a version of
kitty where it is known to work well.
> I don't think we need to change anything for Esc handling. The
> current code has some tricks to handle a single Esc. When the Esc
> arrives as an escape sequence then everything works as before. Not
> using the single-Esc handling doesn't have any advantage, it just
> won't be used.
Yes, I agree that the Esc handling in vim doesn't need to be changed.
It was just an example of how the protocol can be used for proper
separation of the key and control sequences, which can be an issue in
some programs. For instance tmux waits 500ms by default after an
escape character to determine if it's the key or a control sequence.
Yes, this ambigious use of Esc has always been a problem. But we found
ways to deal with it.
> Why not implement modifyOtherKeys? That's what xterm supports and
> it's working fine already. I have not yet seen a reason why yet
> another protocol is going to save the world. The Kitty docs mention
> some reasons that are irrelevant for Vim.
I suppose that's a good question. The reason I went here to vim is
that the problem I have is that mappings I have with keys using ctrl
in vim stops working after some keys are pressed (because
`seenModifyOtherKeys` is set to true), so it seemed most natural to
change vim. And the most straightforward way to fix this seemed to be
to get vim to accept CSI u keys without modifiers and enable the kitty
keyboard protocol.
Accepting those keys doesn't do any harm. Enabling the protocol
(without the user doing that or asking for it) is something completely
different.
Another argument to support modifyOtherKeys is that kitty mostly behaves
like an xterm, the default $TERM is "xterm-kitty". Implementing
modifyOtherKeys like xterm does fits in with that.
I understand that the kitty protocol supports more, but it appears most
users are totally satisfied with what modifyOtherKeys offers.
> First of all there is the risc that this code shows up on terminals.
> We have had the same problem with the cursor position report. I
> actually noticed Kitty gave an error message for one of the requests
> we send. Also, this seems like a terminal property that should be in
> terminfo/termcap, not something that requires an async check.
Hm, not sure about this. @kovidgoyal: Maybe you have some input here?
Just start Kitty without arguments, run Vim in that kitty instance, then
in the terminal where it was started I see:
[289 11:58:46.970942] [PARSE ERROR] Unrecognized DCS code: 0x7a
[289 11:58:46.970957] [PARSE ERROR] Unknown CSI code: 'm' with start_modifier: '' and end_modifier: '%' and parameters: '0'
That messes up whatever I'm doing in that terminal. Perhaps there is a
kitty argument to silence this, I haven't looked for it.
> For modifyOtherKeys we can detect whether it is working. We could do
> it for this one, but I wonder if it makes any difference in what we
> do with the keys. It is important that everything goes back to
> normal when exiting or when executing a shell command.
If you send `CSI < u` when vim exits, everything goes back to normal.
This seems analogous to sending `CSI > 4 ; m` to me, which you have to
send on exit for things to go back to normal after you've sent `CSI >
4 ; 2 m`.
Yes, this is in the t_TE entry. Adding it there, or instead of the
modifyOtherKeys code, is probably sufficient, Vim already makes sure to
output that when needed. Of course when Vim is killed it doesn't
happen. Does the shell "reset" disable the protocol?
> I suppose if a user does change t_TI and t_TE it would just work.
Yes, so now with this patch in, I can set it and get it working
properly for me at least. It would be nicer if kitty and vim worked
well together out of the box though.
Well, if kitty implements modifyOtherKeys then I don't have to do
anything :-). At least that is something under kitty's control.
Which reminds me I have to dive into what libvterm does with
modifyOtherKeys, I don't think it is 100% right.
…--
SIGFUN -- signature too funny (core dumped)
/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
|
Contributor
|
> > I don't think we need to change anything for Esc handling. The
> > current code has some tricks to handle a single Esc. When the Esc
> > arrives as an escape sequence then everything works as before. Not
> > using the single-Esc handling doesn't have any advantage, it just
> > won't be used.
It definitely does. There is no magic trick possible that can
distinguish between a single esc and the start of an escape sequence.
You have to wait, thereby injecting latency into handling of esc key
presses. See your own :help ttimeoutlen
Once you move to a properly designed keyboard escape protocol you no
longer need to wait, since *all* key presses are full escape sequences,
so a single esc byte is never an esc key press.
The point is that most terminals will still send Esc as a single byte,
thus the handling for that must remain. And for Kitty we don't need to
do anything different. You can set 'ttimeoutlen' to any (large) value
and it just works.
> > Why not implement modifyOtherKeys? That's what xterm supports and
> > it's working fine already. I have not yet seen a reason why yet
> > another protocol is going to save the world. The Kitty docs
> > mention some reasons that are irrelevant for Vim.
because modifyOtherKeys is badly designed and doesn't solve the entire
problem space. Are you really suggesting that because you are happy with
modifyOtherKeys everybody else should be as well? I'll just point out
that modern terminal editors are all adding support for it: nvim,
kakoune, dte, etc.
I'm saying that modifyOtherKeys solves most of the problems with
modifiers, and Vim users have not mentioned things that are missing. I
understand that it's a partial solution, but if it works for most people
then why not use it? Applications will have to implement it anyway,
since most terminals do support modifyOtherKeys. I assume nvim, kakoune
(never heard of it) and dte (also never heard of it), also implement
modifyOtherKeys, otherwise they wouldn't work well in most popular
terminals.
Claming that you have a great standard doesn't mean that everybody will
take the effort to implement it. Even utf-8 support took a lot of
effort to get implemented, while it was obvious a very good solution
(although there was objection to it as well).
> I suppose that's a good question. The reason I went here to vim is
> that the problem I have is that mappings I have with keys using ctrl
> in vim stops working after some keys are pressed (because
> `seenModifyOtherKeys` is set to true), so it seemed most natural to
> change vim. And the most straightforward way to fix this seemed to
> be to get vim to accept CSI u keys without modifiers and enable the
> kitty keyboard protocol.
>
> > First of all there is the risc that this code shows up on
> > terminals. We have had the same problem with the cursor position
> > report. I actually noticed Kitty gave an error message for one of
> > the requests we send. Also, this seems like a terminal property
> > that should be in terminfo/termcap, not something that requires an
> > async check.
terminfo is tied to the limitations of ncurses and xterm. It
took Thomas Dickey a decade to add support for truecolor to ncurses. It
cant be relied upon for any modern terminal features.
Yeah, and then people set $TERM to some value "because it seems to work
better". It would be much better if we can directly ask the terminal
for its "terminfo" and all properties. That will also go through ssh
(remote system has a terminal that the local system doesn't have an
entry for), tmux and screen (which may filter it because they add their
own stuff), etc. But I haven't thought of a good way to implement it.
It has to be near perfect, otherwise we'll get stuck in long discussions
and it won't get widely accepted.
The kitty keyboard protocol can be detected at runtime without
depending on the value of TERM which is often wrongly set by users and
is what terminfo uses to key its database:
https://sw.kovidgoyal.net/kitty/keyboard-protocol/#detection-of-support-for-this-protocol
IIRC vim already queries the terminal emulator to detect various things, add
the above to that query as well. I don't know of any terminal emulator
that misbehaves when you send it CSI ? u if you do a citation would be
most welcome.
That is the thing, you can't predict that. Usually it takes months for
someone to complain about weird characters showing up that go away with
CTRL-L. That is why I'm reluctant to add something like this.
Also, it can take several seconds before all this setup is done. This
has side effects. E.g, when Vim receives information about the number
of supported colors all the highlighting needs to be re-initialized.
Usually it is fast enough, but once in a while you suddenly see the
colors changing.
With this keyboard protocol the problem will be that mappings (usually
defined early in startup) will suddenly work differently. For
modifyOtherKeys it took quite a few tries to avoid the side effect of
detecting that modifyOtherKeys was enabled and still handling mappings
that were already defined. The code is tricky and I don't really look
forward to doing this again for the kitty protocol.
Thus, if Kitty implements modifyOtherKeys (which probably isn't much
work) then Vim doesn't need to change and we're quickly in a good
situation. Going for the kitty protocol means lots of works, some bugs
for some time, and in the end some rare modifier combinations work that
didn't work before (but users already got used to those not working and
they still don't work on other systems so only few people will use
them).
…--
BRIDGEKEEPER: What is the air-speed velocity of an unladen swallow?
ARTHUR: What do you mean? An African or European swallow?
BRIDGEKEEPER: Er ... I don't know that ... Aaaaarrrrrrggghhh!
BRIDGEKEEPER is cast into the gorge.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
|
|
On Sun, Oct 16, 2022 at 04:30:35AM -0700, Bram Moolenaar wrote:
> > > I don't think we need to change anything for Esc handling. The
> > > current code has some tricks to handle a single Esc. When the Esc
> > > arrives as an escape sequence then everything works as before. Not
> > > using the single-Esc handling doesn't have any advantage, it just
> > > won't be used.
>
> It definitely does. There is no magic trick possible that can
> distinguish between a single esc and the start of an escape sequence.
> You have to wait, thereby injecting latency into handling of esc key
> presses. See your own :help ttimeoutlen
>
> Once you move to a properly designed keyboard escape protocol you no
> longer need to wait, since *all* key presses are full escape sequences,
> so a single esc byte is never an esc key press.
The point is that most terminals will still send Esc as a single byte,
thus the handling for that must remain. And for Kitty we don't need to
do anything different. You can set 'ttimeoutlen' to any (large) value
and it just works.
My point is that I would like this ecosystem to move forward.
modifyOtherKeys is a partial and sub-standard solution. Someone needs to
move the ecosystem forward. The kitty keyboard protocol does exactly
that. It comprehensively solves every key handling issue there is in
terminals. If you disagree, I would be very glad to hear how the protocol
falls short. I have done what I can, it would be nice if other people in
the ecosystem also chipped in some effort and we can put the whole issue
of keys in terminals to bed, forever.
> > > Why not implement modifyOtherKeys? That's what xterm supports and
> > > it's working fine already. I have not yet seen a reason why yet
> > > another protocol is going to save the world. The Kitty docs
> > > mention some reasons that are irrelevant for Vim.
>
> because modifyOtherKeys is badly designed and doesn't solve the entire
> problem space. Are you really suggesting that because you are happy with
> modifyOtherKeys everybody else should be as well? I'll just point out
> that modern terminal editors are all adding support for it: nvim,
> kakoune, dte, etc.
I'm saying that modifyOtherKeys solves most of the problems with
modifiers, and Vim users have not mentioned things that are missing. I
It doesn't. You can only use 4 modifier keys, not all of them (hyper and
meta (not alt)) are not supported. It also does not allow you to use
special/function keys, since it does not specify an encoding for all but
the most common ones.
understand that it's a partial solution, but if it works for most people
then why not use it? Applications will have to implement it anyway,
since most terminals do support modifyOtherKeys. I assume nvim, kakoune
(never heard of it) and dte (also never heard of it), also implement
modifyOtherKeys, otherwise they wouldn't work well in most popular
terminals.
Claming that you have a great standard doesn't mean that everybody will
take the effort to implement it. Even utf-8 support took a lot of
If you dont want to do the work, that's your choice, of course. It would
be good if you at least indicated that you are willing to accept a PR
that implements support for it via an escape code query, if someone else
is willing to do most of the work. As a fellow maintainer, I know that
it's not that simple, and that PRs can sometimes have large ongoing
maintenance burdens that the maintainer is on the hook for. But I hope
you will be willing to bear that load once you have read the rest of my
arguments.
effort to get implemented, while it was obvious a very good solution
(although there was objection to it as well).
> > I suppose that's a good question. The reason I went here to vim is
> > that the problem I have is that mappings I have with keys using ctrl
> > in vim stops working after some keys are pressed (because
> > `seenModifyOtherKeys` is set to true), so it seemed most natural to
> > change vim. And the most straightforward way to fix this seemed to
> > be to get vim to accept CSI u keys without modifiers and enable the
> > kitty keyboard protocol.
> >
> > > First of all there is the risc that this code shows up on
> > > terminals. We have had the same problem with the cursor position
> > > report. I actually noticed Kitty gave an error message for one of
> > > the requests we send. Also, this seems like a terminal property
> > > that should be in terminfo/termcap, not something that requires an
> > > async check.
>
> terminfo is tied to the limitations of ncurses and xterm. It
> took Thomas Dickey a decade to add support for truecolor to ncurses. It
> cant be relied upon for any modern terminal features.
Yeah, and then people set $TERM to some value "because it seems to work
better". It would be much better if we can directly ask the terminal
for its "terminfo" and all properties. That will also go through ssh
You can, there is an escape code already existing to do just that. If
you are interested, I will tell you more about it. It's supported in
xterm which seems to be your go to reference terminal, and kitty and
many others as well.
(remote system has a terminal that the local system doesn't have an
entry for), tmux and screen (which may filter it because they add their
own stuff), etc. But I haven't thought of a good way to implement it.
It has to be near perfect, otherwise we'll get stuck in long discussions
and it won't get widely accepted.
> The kitty keyboard protocol can be detected at runtime without
> depending on the value of TERM which is often wrongly set by users and
> is what terminfo uses to key its database:
> https://sw.kovidgoyal.net/kitty/keyboard-protocol/#detection-of-support-for-this-protocol
>
> IIRC vim already queries the terminal emulator to detect various things, add
> the above to that query as well. I don't know of any terminal emulator
> that misbehaves when you send it CSI ? u if you do a citation would be
> most welcome.
That is the thing, you can't predict that. Usually it takes months for
someone to complain about weird characters showing up that go away with
CTRL-L. That is why I'm reluctant to add something like this.
I understand it is a risk for you, but you can take heart from the fact
that nvim has implemented it and no one has reported any issues with it.
You can also implement it behind a user settable option to start with so
your userbase can test it. Progress will only happen if people are
willing to take *some* risk.
Also, it can take several seconds before all this setup is done. This
has side effects. E.g, when Vim receives information about the number
of supported colors all the highlighting needs to be re-initialized.
Usually it is fast enough, but once in a while you suddenly see the
colors changing.
With this keyboard protocol the problem will be that mappings (usually
defined early in startup) will suddenly work differently. For
modifyOtherKeys it took quite a few tries to avoid the side effect of
detecting that modifyOtherKeys was enabled and still handling mappings
that were already defined. The code is tricky and I don't really look
forward to doing this again for the kitty protocol.
That's exactly the point. modifyOtherKeys is very badly designed. You
cant know if and when it is in operation. That is why you need all these
tricky code paths to deal with it. This pain was exactly what motivated
me to create the kitty keyboard protocol in the first place. I write a
lot of terminal programs and having *simple* and *robust* key handling in
them was exceedingly difficult before the kitty keyboard protocol. You
have already gone through all this pain because you are awesome and want
your userbase to to be able to use more keys/modifiers. But, surely you
would not want everyone writing a terminal program to go through this
pain, forever.
I obviously am not familiar with vim's codebase so I cannot pretend to
know how difficult it would be for you to implement. I will just outline
how this support would work in a abstract sense.
0) If your user's have enabled an option to support this protocol, do
the following.
1) Send the query to detect if the protocol is supported, as part of
your initialization queries.
2) Until you receive a response continue handling key events as you
currently do
3) If you receive a response indicating the protocol is supported,
send the escape code to turn it on and another query escape code with
it. As soon as you see the response to the query escape code, you switch to a different code path
that handles only the new protocols events and ignores old style key
bytes (which you wont see any more of anyway).
4) On suspend/exit, you send the escape code to revert the terminal to
traditional key handling.
This code path will literally be 100 lines of code with no edge cases
(and an autogenerated table of mappings from numbers to keys).
The only risk here to you is a user explicitly turning on the option
and then using vim in a terminal that doesn't support the protocol *and*
that somehow breaks on seeing the query escape code (which has been
tested on dozens of terminals by me, or if you dont trust me, nvim
already).
The other risk is if vim crashes leaving the terminal in the state where
it is using the extended protocol. But vim crashes are pretty rare, at
least in my experience of using it for 15 odd years :)
Over time, as you gather confidence in this approach and more and more
terminals support the protocol, you can switch the default of the option
in (0) to on. Maybe someday, in the next century, Bram Jr. could even dispense
with the query in (1).
Thus, if Kitty implements modifyOtherKeys (which probably isn't much
work) then Vim doesn't need to change and we're quickly in a good
situation. Going for the kitty protocol means lots of works, some bugs
for some time, and in the end some rare modifier combinations work that
didn't work before (but users already got used to those not working and
they still don't work on other systems so only few people will use
them).
As I said before I want the ecosystem to move forward, modifyOtherKeys
is moving backwards. If I support it, it just means people will be lazy
and pick the sub-optimal solution. Throughout my development of kitty I
have been very strict about doing the *right* thing even if it means
kitty suffers as a result, because I deeply care about this ecosystem.
And the only lever I have to move it is what kitty will and will not do.
…--
_____________________________________
Dr. Kovid Goyal
https://www.kovidgoyal.net
https://calibre-ebook.com
_____________________________________
|
Contributor
|
My point is that I would like this ecosystem to move forward.
modifyOtherKeys is a partial and sub-standard solution. Someone needs to
move the ecosystem forward. The kitty keyboard protocol does exactly
that. It comprehensively solves every key handling issue there is in
terminals. If you disagree, I would be very glad to hear how the protocol
falls short. I have done what I can, it would be nice if other people in
the ecosystem also chipped in some effort and we can put the whole issue
of keys in terminals to bed, forever.
Don't expect much from others. If you want to move this forward, you
will have to do most of the work. Or convince others to join in. Don't
expect a thousand app maintainers to do much, you will have to send them
patches. It's easy to underestimate the work required and overestimate
the gain people will experience.
> I'm saying that modifyOtherKeys solves most of the problems with
> modifiers, and Vim users have not mentioned things that are missing. I
It doesn't. You can only use 4 modifier keys, not all of them (hyper and
meta (not alt)) are not supported. It also does not allow you to use
special/function keys, since it does not specify an encoding for all but
the most common ones.
You don't need to convince me that modifyOtherKeys isn't perfect, we
know that. But it's around and sufficient for most people. In Vim you
can always map the raw sequence to make a key work, so long as it
differs from other keys.
Was there a proposal and review of this new protocol? Did enough
people get involved? I would like to hear what Thomas Dickey has to
say. He knows the modifyOtherKeys mechanism probably better than
anyone else.
> understand that it's a partial solution, but if it works for most people
> then why not use it? Applications will have to implement it anyway,
> since most terminals do support modifyOtherKeys. I assume nvim, kakoune
> (never heard of it) and dte (also never heard of it), also implement
> modifyOtherKeys, otherwise they wouldn't work well in most popular
> terminals.
>
> Claming that you have a great standard doesn't mean that everybody will
> take the effort to implement it. Even utf-8 support took a lot of
If you dont want to do the work, that's your choice, of course. It would
be good if you at least indicated that you are willing to accept a PR
that implements support for it via an escape code query, if someone else
is willing to do most of the work. As a fellow maintainer, I know that
it's not that simple, and that PRs can sometimes have large ongoing
maintenance burdens that the maintainer is on the hook for. But I hope
you will be willing to bear that load once you have read the rest of my
arguments.
The query is the problem. I already mentioned that it is better to use
the version response. That is an existing mechanism, it avoids doing
something new and unpredictable. I haven't heard what version responses
kitty may send, I can only see what it sends now.
> Yeah, and then people set $TERM to some value "because it seems to work
> better". It would be much better if we can directly ask the terminal
> for its "terminfo" and all properties. That will also go through ssh
You can, there is an escape code already existing to do just that. If
you are interested, I will tell you more about it. It's supported in
xterm which seems to be your go to reference terminal, and kitty and
many others as well.
You mean the mechanism to request key codes? Vim already uses that.
The request is something like "\033P+q%02x%02x\033\\" and the response
comes in the form "<Esc>P1+r<name>=<string><Esc>\". It's not working
well enough that I persued using it more widely. Main problem is that
the response is too bulky. And to do it properly would require
requesting much more, which is a conflict that can't be solved.
If you mean something else, please give a reference to the docs.
BTW: What I was thinking of does not use escape codes, since those are
mixed with what is typed. On a local system there would be a way to use
a back channel. But that won't work remotely, and it's most useful for
remote terminals.
> That is the thing, you can't predict that. Usually it takes months for
> someone to complain about weird characters showing up that go away with
> CTRL-L. That is why I'm reluctant to add something like this.
I understand it is a risk for you, but you can take heart from the fact
that nvim has implemented it and no one has reported any issues with it.
You can also implement it behind a user settable option to start with so
your userbase can test it. Progress will only happen if people are
willing to take *some* risk.
There are many things that seemed to work fine in nvim, and people
started complaining only when the feature was added to Vim. The user
base of nvim simply isn't wide enough, it tends to consist of people who
use the latest stuff. While Vim users are everywhere, often using old
stuff.
Putting it behind an option just causes it to take longer before
problems are reported. An advantage is that someone who experiences a
problem can disable the feature. But then they often don't file a
report and this goes unnoticed and never gets solved, while people have
to keep tweaking their options.
That's exactly the point. modifyOtherKeys is very badly designed. You
cant know if and when it is in operation. That is why you need all these
tricky code paths to deal with it. This pain was exactly what motivated
me to create the kitty keyboard protocol in the first place.
The point is that the problems with modifyOtherKeys are solved to a point
where it's working quite well. While the kitty protocol is not widely
supported. In fact, I don't think I use a single terminal that supports it.
I write a lot of terminal programs and having *simple* and *robust*
key handling in them was exceedingly difficult before the kitty
keyboard protocol. You have already gone through all this pain because
you are awesome and want your userbase to to be able to use more
keys/modifiers. But, surely you would not want everyone writing a
terminal program to go through this pain, forever.
If this protocol is so wonderful, how come popular terminals don't
support it?
I obviously am not familiar with vim's codebase so I cannot pretend to
know how difficult it would be for you to implement. I will just outline
how this support would work in a abstract sense.
0) If your user's have enabled an option to support this protocol, do
the following.
1) Send the query to detect if the protocol is supported, as part of
your initialization queries.
2) Until you receive a response continue handling key events as you
currently do
That won't work. We can't handle any key events, and especially apply
mappings, before we know what the terminal sends. Or anticipate what is
sent and do the difficult things we had to do for modifyOtherKeys.
3) If you receive a response indicating the protocol is supported,
send the escape code to turn it on and another query escape code with
it. As soon as you see the response to the query escape code, you
switch to a different code path
that handles only the new protocols events and ignores old style key
bytes (which you wont see any more of anyway).
This also requires going back to all the mappings that a user has
defined and adjust them for the changed codes.
There also is some time between activating the mode and getting the
first code that uses it. In between both sequences may be received.
This may seem unlikely, but this happens during startup and users tend
to start typing even before the text is displayed. I know I do, e.g.
hit the End key to go to the end of the file (well, I type "G" for that,
it's not the best example).
4) On suspend/exit, you send the escape code to revert the terminal to
traditional key handling.
That's the easy part.
This code path will literally be 100 lines of code with no edge cases
(and an autogenerated table of mappings from numbers to keys).
No, it's much more complicated. Also take into account that terminals
will have bugs in the protocol, which will get fixed, and then we may
have to deal with both versions. And when more people start using no
doubt there will be a second version of the protocol.
The only risk here to you is a user explicitly turning on the option
and then using vim in a terminal that doesn't support the protocol *and*
that somehow breaks on seeing the query escape code (which has been
tested on dozens of terminals by me, or if you dont trust me, nvim
already).
The other risk is if vim crashes leaving the terminal in the state where
it is using the extended protocol. But vim crashes are pretty rare, at
least in my experience of using it for 15 odd years :)
It mostly happens to me when reproducing a bug :-). We already have
this situation with modifyOtherKeys, and very ocasionally someone
complains about getting these weird codes in their shell. I don't think
there is a way to avoid that (should the shell send a "disable all weird
codes" sequence after a command finished?). It appears to happen
infrequently enough, the advantage of the modifier support justifies it.
Over time, as you gather confidence in this approach and more and more
terminals support the protocol, you can switch the default of the
option in (0) to on. Maybe someday, in the next century, Bram Jr.
could even dispense with the query in (1).
If you manage to convince Thomas Dickey to add this protocol to Xterm
then we are in a different situation.
> Thus, if Kitty implements modifyOtherKeys (which probably isn't much
> work) then Vim doesn't need to change and we're quickly in a good
> situation. Going for the kitty protocol means lots of works, some bugs
> for some time, and in the end some rare modifier combinations work that
> didn't work before (but users already got used to those not working and
> they still don't work on other systems so only few people will use
> them).
As I said before I want the ecosystem to move forward, modifyOtherKeys
is moving backwards. If I support it, it just means people will be lazy
and pick the sub-optimal solution. Throughout my development of kitty I
have been very strict about doing the *right* thing even if it means
kitty suffers as a result, because I deeply care about this ecosystem.
And the only lever I have to move it is what kitty will and will not do.
Well, it's your choice. What can happen is that someone comes up with a
terminal like kitty that does support modifyOtherKeys, and that one
gains popuplarity quickly.
…--
A special law prohibits unmarried women from parachuting on Sunday or she
shall risk arrest, fine, and/or jailing.
[real standing law in Florida, United States of America]
/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
|
|
On Sun, Oct 16, 2022 at 07:38:00AM -0700, Bram Moolenaar wrote:
> My point is that I would like this ecosystem to move forward.
> modifyOtherKeys is a partial and sub-standard solution. Someone needs to
> move the ecosystem forward. The kitty keyboard protocol does exactly
> that. It comprehensively solves every key handling issue there is in
> terminals. If you disagree, I would be very glad to hear how the protocol
> falls short. I have done what I can, it would be nice if other people in
> the ecosystem also chipped in some effort and we can put the whole issue
> of keys in terminals to bed, forever.
Don't expect much from others. If you want to move this forward, you
will have to do most of the work. Or convince others to join in. Don't
expect a thousand app maintainers to do much, you will have to send them
patches. It's easy to underestimate the work required and overestimate
the gain people will experience.
I don't expect anything from anyone. I didn't open this PR one of
your users did. I only commented because I was asked to. I can see from
your responses that you are not interested in doing the work, the rest
is all just rationalizations to justify that. So I wont waste anymore of
your time, good luck.
|
But vim users have mentioned things that are missing, even if they have not used the word "modifyOtherKeys". E.g., I know I've seen people wonder why they can't make the Cmd key on an Apple keyboard be part of the LHS of a console vim mapping---even after using a terminal emulator that doesn't automatically capture the "Cmd" before it gets to whatever program runs in the terminal. I wonder that myself! (I might've even been one of the people who asked about that.) It's flippin' 2022 and I can't make e.g., Control-Opt-Cmd-h be a vim LHS. modifyOtherKeys doesn't handle the Cmd key, which is an extremely convenient and obvious modifier for anyone on an Apple keyboard. It's not some obscure thing. Plus, modifyOtherKeys has undesirable side effects. |
Contributor
|
> I'm saying that modifyOtherKeys solves most of the problems with
> modifiers, and Vim users have not mentioned things that are missing.
But vim users *have* mentioned things that are missing, even if they
have not used the word "modifyOtherKeys".
E.g., I know I've seen people wonder why they can't make the Cmd key
on an Apple keyboard be part of the LHS of a console vim
mapping---even after using a terminal emulator that doesn't
automatically capture the "Cmd" before it gets to whatever program
runs in the terminal. I wonder that myself! (I might've even been
one of the people who asked about that.) It's flippin' 2022 and I
can't make e.g., Control-Opt-Cmd-h be a vim LHS.
I suppose the Terminal app doesn't support it (it is not a very good
terminal emulater, but everyone has it).
If you use Kitty and enable the mouse protocol, you can map those keys,
right? You have to use the escape sequence, but it should work.
modifyOtherKeys doesn't handle the Cmd key, which is an *extremely*
convenient and obvious modifier for anyone on an Apple keyboard. It's
not some obscure thing. Plus, modifyOtherKeys has undesirable side
effects.
Please be specific. What terminal is this with? I don't know a common
terminal that supports modifyOtherKeys and is used an Mac.
…--
bashian roulette:
$ ((RANDOM%6)) || rm -rf ~
/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
|
trygveaa
added a commit
to trygveaa/vim
that referenced
this pull request
Oct 18, 2022
As mentioned in issue vim#7562 and patch 8.2.2246, cursor keys are not recognized at the hit-Enter prompt after executing an external command. While arrow keys were fixed by that, the Home and End keys are also considered cursor keys by xterm and also change control sequences between normal and application mode, so they were still not working. To be honest, the reason I discovered this is that after enabling the kitty keyboard protocol as discussed in PR vim#11364 the Home and End keys stopped working. While debugging this, I noticed this inconsistency between the handling of the arrow keys and Home/End keys since the arrow keys still worked. The reason for this is that in this mode, kitty sends the arrow and Home/End keys the same way as in normal terminal mode, and vim supports that for arrow keys, but not for Home/End keys. I would hesitate to change the builtin termcap for xterm to just fix behavior in kitty, but since this is an inconsistency between the handling of the arrow keys and the Home/End keys that I don't think should be there, and since it actually fixes the vim#7562 issue for Home/End keys in xterm I think it makes sense to do this change. And it happens to also fix the problem I have with Home/End keys in the kitty keyboard protocol (at least as long as TERM is some xterm name).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The kitty terminal emulator, as well as some others, suppors sending keys as
CSI {key} u, like the keys with modifiers that's already supported, but for keys without any modifiers. The most notable example is escape being sent asCSI 27 u, to be able to distinguish the key press from the start of an escape sequence. It's also used to support some "special" keys, like media keys and print screen.The main reason for adding support for this is a problem with kitty and the existing key handling in vim. By default kitty has support for keys that are not traditionally supported in terminals, like super+, and sends those as keys with modifiers. E.g. super+q is
CSI 113 ; 9 u. If I press such a key, vim setsseenModifyOtherKeysto true and stops processing normal control keys, so the bindings i have for those stops working because kitty sends them as normal control keys by default.I can set kitty to send control keys as keys with modifiers by enabling disambiguate escape codes by sending
CSI > 1 u. This makes the control keys work again. However, this also changes the escape key to be sent asCSI 27 u, so that stops working. By adding support for this, all keys work as far as I know.The problem exists by default when I'm not enabling disambiguate escape codes though, so it would be nice if vim could enable this automatically. I think it should be safe to send it to any terminal emulator, but alternatively vim could query for support of the protocol by sending
CSI ? uand check if it gets a reply likeCSI ? flags u.Note that none of the escape sequences I wrote actually contains spaces, they were just added for readability.
You can read more about the keyboard handling in kitty here: https://sw.kovidgoyal.net/kitty/keyboard-protocol/
There's also an issue in kitty's repo with some discussion here: kovidgoyal/kitty#4075