[vim/vim] mapping stop working "randomly" (Issue #11403)
Louis Régnier
Steps to reproduce
Hi, I use basic mapping like:
nmap <C-H> <C-W>h
nmap <C-J> <C-W>j
nmap <C-K> <C-W>k
nmap <C-L> <C-W>l
But sometimes after moving in and out of my terminal, the mapping stop working, after this behave like there is no mapping at all. For example <C-L> will clear the screen for a micro-second instead of switching windows.
<C-W>h/j/k/l still work when my mapping stop working.
Also to move around my terminal windows, I use a mapping also based on ctrl and os key, I don't know if it could lead to a strange behavior regarding vim, I don't think so because the issue appears in other terminal without those terminal mappings.
My configuration is pretty normal, I use termdebug and man plugins.
Loading them in my .vimrc following:
runtime ftplugin/man.vim
packadd termdebug
:nmap show correct mapping when the bug occurs
n <C-L> <C-W>l
n <C-K> <C-W>k
n <C-J> <C-W>j
n <C-H> <C-W>h
When it appears, if I save the session using :mks and inspect the Session.vim.
The previous mapping appears early in the file, but there is also "weird" mapping
I don't know if thoses mappings here are normal.
How can I investigate more precisely this behavior ?
Expected behaviour
Mapping should work all the time.
Version of Vim
9.0
Environment
Operating system: Gentoo:
Terminal: kitty (reproduced on many terminals: foot, alacritty)
$TERM: xterm-kitty
shell: zsh
I also disabled modifyOtherKeys only for kitty terminal since it doesn't support it.
Using:
if &term == "xterm-kitty"
let &t_TI = ''
let &t_TE = ''
endif
Logs and stack traces
No response
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
I suspect that is because modifyOtherKeys is not set and Vim does not support the CSI u standard from kitty. So I guess it falls back to see <c-l> as seeing the actual CTRL-L which redraws the screen, also <C-j> by default is just Enter, so I would expect problems which those maps. I would also expect problems with <C-H>, which is usually Backspace, but I believe this does nothing (useful) in normal mode, so it may be okay.
However, just some days ago, b9c09c1 was commited, which should make Vim work better with CSI u terminal mode.
There is a lengthy discussion about that mode at #11364 but I am not sure from that what Vim does support and what not, also there was a mention to set the t_TI and t_TE terminal options to support CSI u mode better. Not sure if this would be the right thing to do, but if it is, this should be mentioned in the documentation.
Let me ping @trygveaa here, so he can comment on this specifically for Kitty support. Thanks.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
> ### Steps to reproduce
>
> Hi, I use basic mapping like:
>
> ```
> nmap <C-H> <C-W>h
> nmap <C-J> <C-W>j
> nmap <C-K> <C-W>k
> nmap <C-L> <C-W>l
> ```
> But sometimes after moving in and out of my terminal, the mapping stop
> example `<C-L>` will clear the screen for a micro-second instead of
> switching windows.
> `<C-W>h/j/k/l` still work when my mapping stop working.
>
> Also to move around my terminal windows, I use a mapping also based on
> ctrl and os key, I don't know if it could lead to a strange behavior
> regarding vim, I don't think so because the issue appears in other
> terminal without those terminal mappings.
>
> My configuration is pretty normal, I use termdebug and man plugins.
> Loading them in my .vimrc following:
> ```
> runtime ftplugin/man.vim
> packadd termdebug
> ```
>
> :nmap show correct mapping when the bug occurs
> ```
> n <C-L> <C-W>l
> n <C-K> <C-W>k
> n <C-J> <C-W>j
> n <C-H> <C-W>h
You could add ":verbose" to get a bit more information and check that
the mappings themselves were not changed.
You could also press those keys when the mappings work in Insert mode,
prefixed with CTRL-V, to see what you get. Repeat this when the
mappings don't work and check for a difference.
> When it appears, if I save the session using :mks and inspect the
> Session.vim. The previous mapping appears early in the file, but
> there is also "weird" mapping
> 
> I don't know if thoses mappings here are normal.
>
> How can I investigate more precisely this behavior ?
keyboard protocol. You get a different escape sequence for keys then,
especially with modifiers. You can try disabling it:
let &t_TE = "\<Esc>[<u"
And then output it by doing some shell command, e.g. ":!ls".
--
"I love deadlines. I especially like the whooshing sound they
make as they go flying by."
-- Douglas Adams
/// 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 ///
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Trygve Aaberge
Yes, this sounds like the issue I've been having (described in #11364), except that you also experience it in other terminals in addition to kitty.
I know this issue is triggered in kitty when certain keys are pressed because seenModifyOtherKeys is set to true. However, it has been happening more often for me recently, and also at times where I've not been aware of pressing those keys. I assumed I had pressed them by accident, but since it seems to happen more often, and since you experience it in other terminals (where I'm not aware of any keys triggering this), maybe there is something else triggering it?
h/j/k/l still work when my mapping stop working.
Interesting, I had not noticed that the default mappings keep working and only my user defined mappings stop working, but I see now this is the case for me too. @brammool: What is the reason for (only) user defined mappings sent as control characters being disabled when seenModifyOtherKeys is true?
Since you are using Kitty, perhaps it gets switched to using the kitty keyboard protocol. You get a different escape sequence for keys then, especially with modifiers.
So at least if this is the same problem as what I see (which seem very likely), the problem here is not that kittys keyboard protocol is switched on. The problem is that control characters stop working for custom mappings when seenModifyOtherKeys is set to true. So for the mapping nmap <C-H> <C-W>h, the terminal sends \x08 when you press ctrl-h to invoke it, but that doesn't trigger the mapping when seenModifyOtherKeys is true.
Enabling kittys keyboard protocol was just my workaround for this, since kitty doesn't send these control characters when it's on.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
Note, with 9.0.0794 Vim will tell whether it saw modifyOtherKeys when using :verbose :map I believe. So can you please check and report here, what an updated vim reports when you see this issue?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Louis Régnier
I'm currently testing vim with upstream patches, I'll let you know if I hit this issue again.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Trygve Aaberge
Note, with 9.0.0794 Vim will tell whether it saw
modifyOtherKeyswhen using:verbose :mapI believe. So can you please check and report here, what an updated vim reports when you see this issue?
Yes, if I trigger this in kitty by pressing Super-<some_key>, modifyOtherKeys is seen.
Before pressing Super-<some_key>:
n <C-H> <C-W>h
Last set from ~/dotfiles/.vim/vimrc line 440
After pressing Super-<some_key>:
Seen modifyOtherKeys: true
n <C-H> <C-W>h
Last set from ~/dotfiles/.vim/vimrc line 440
I've not been able to reproduce this issue in foot or alacritty as mentioned by @louregni though, so would be good to get a confirmation if this is the case for those as well.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Trygve Aaberge
I've not been able to reproduce this issue in foot or alacritty as mentioned by @louregni though, so would be good to get a confirmation if this is the case for those as well.
Ah, in foot it can be triggered by pressing control in combination with certain symbols. E.g. Ctrl-.. This sets seenModifyOtherKeys to true.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
I remember we had a discussion here about foot only supporting modifyOtherKeys version 1 and as far as I remember they added support for version 2 as well, so you may want to check to update foot terminal.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Trygve Aaberge
I'm running foot 1.13.1, which is the latest release. I haven't tested master though. I'm guessing your referring to issue #9014. I just found that a couple of minutes ago and am reading it now.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Daniel Eklöf
Foot has supported modifyOtherKeys=2 since 1.10.0 (current release is 1.13.1). My understanding is vim is still not enabling it though. Users are required to manually set t_TI and t_TE.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Trygve Aaberge
Ah, you're right. vim is only enabling modifyOtherKeys for terminals which have xterm or something similar in TERM. If I set t_TI and t_TE manually, or set TERM=xterm (not that I should do that, but just to confirm now), it works correctly in foot.
t_TI in vim is set from the builtin xterm terminfo defined here: https://github.com/vim/vim/blob/3c708c43908ba44f075bbaa7daf584c6b46d9723/src/term.c#L805
And this is how vim determines if that terminfo should be used: https://github.com/vim/vim/blob/3c708c43908ba44f075bbaa7daf584c6b46d9723/src/os_unix.c#L2353-L2369
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
> Yes, this sounds like the issue I've been having (described in
> #11364), except that you also experience it in other terminals in
> addition to kitty.
>
> I know this issue is triggered in kitty when certain keys are pressed
> because `seenModifyOtherKeys` is set to true. However, it has been
> happening more often for me recently, and also at times where I've not
> been aware of pressing those keys. I assumed I had pressed them by
> accident, but since it seems to happen more often, and since you
> experience it in other terminals (where I'm not aware of any keys
> triggering this), maybe there is something else triggering it?
mode and does not switch it back to normal? Or worse: Vim gets some
keys in the different protocol, switches on modifyOtherKeys, and then
the terminal is switched back. Then Vim obviously gets very confused.
> > <C-W>h/j/k/l still work when my mapping stop working.
>
> the case for me too. @brammool: What is the reason for (only) user
> defined mappings sent as control characters being disabled when
> `seenModifyOtherKeys` is true?
sequence and then the terminal sends something else, which doesn't
match and the mapping doesn't trigger.
When modifyOtherKeys was implemented a lot of effort was put into
supporting two codes for a mapping, since we never know for sure when
the terminal goes into modifyOtherKeys mode. Once it does, we know we
can tell some keys apart that previously produced the same code, and Vim
adapts to that.
Until a few hours ago you could not actually tell whether Vim has
detected a modifyOtherKeys code. I made it show the flag if you use
":verbose map" in patch 9.0.0794.
> > Since you are using Kitty, perhaps it gets switched to using the
> > kitty keyboard protocol. You get a different escape sequence for
> > keys then, especially with modifiers.
>
> So at least if this is the same problem as what I see (which seem very
> likely), the problem here is not that kittys keyboard protocol is
> switched on. The problem is that control characters stop working for
> custom mappings when `seenModifyOtherKeys` is set to true. So for the
> ctrl-h to invoke it, but that doesn't trigger the mapping when
> `seenModifyOtherKeys` is true.
extra information in the key codes cannot work.
If you actually get 0x08 for CTRL-H then somehow the terminal was
switched back to old style key codes. It must have been in the advanced
mode (modifyOtherKeys or kitty keyboard protocol) at some point,
otherwise the modifyOtherKeys flag would not have been set.
> Enabling kittys keyboard protocol was just my workaround for this,
> since kitty doesn't send these control characters when it's on.
are the same as modifyOtherKeys. Not when other than the first four
modifiers are used.
If you want to see what raw codes Vim is actually getting, use
ch_logfile(). If you do that very early you might even spot where the
code changes.
--
Every time I lose weight, it finds me again!
/// 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 ///
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
> Foot has supported modifyOtherKeys=2 since 1.10.0 (current release is
> Users are required to manually set `t_TI` and `t_TE`.
The mode is only enabled for xterm, because that's the only terminal we
know where it works. If we are able to detect another terminal where it
works (preferably with the termresponse) we could add it. *if* it
actually works.
Some terminals get around lacking support by adding "xterm" in their
name. E.g. kitty defaults to "xterm-kitty". This helps for several
things, and may break some things...
--
The MS-Windows registry is no more hostile than any other bunch of state
information... that is held in a binary format... a format that nobody
understands... and is replicated and cached in a complex and largely
undocumented way... and contains large amounts of duplicate and obfuscated
information... (Ben Peterson)
/// 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 ///
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Trygve Aaberge
Perhaps you execute some shell command that puts kitty in the different mode and does not switch it back to normal? Or worse: Vim gets some keys in the different protocol, switches on modifyOtherKeys, and then the terminal is switched back. Then Vim obviously gets very confused.
No, when I don't set t_TI kitty is not switched to a different mode (or when t_TI is CSI > 4 ; 2 m, because kitty doesn't support xterms modifyOtherKeys). The thing is that by default kitty sends CSI u sequences for some keys. E.g. pressing Super-q sends CSI 113 ; 9 u. So Ctrl-h still sends 0x08, since we're not in a different mode.
Vim sets seenModifyOtherKeys to true when it sees this CSI u sequence, which means 0x08 is not triggering the Ctrl-h mapping anymore.
I read that the argumentation for sending CSI u sequences for some keys by default is so that these keys can be used in applications without implementing support for the full kitty keyboard protocol.
The mappings are not disabled. The mappings are defined for one escape sequence and then the terminal sends something else, which doesn't match and the mapping doesn't trigger.
What I mean by disabled is that at first 0x08 is triggering the Ctrl-h mapping, but after seenModifyOtherKeys is set to true it does not.
When modifyOtherKeys was implemented a lot of effort was put into supporting two codes for a mapping, since we never know for sure when the terminal goes into modifyOtherKeys mode. Once it does, we know we can tell some keys apart that previously produced the same code, and Vim adapts to that. Until a few hours ago you could not actually tell whether Vim has detected a modifyOtherKeys code. I made it show the flag if you use ":verbose map" in patch 9.0.0794.
Right, I read more about it and now understand what it's about. Since e.g. 0x08 can be sent by backspace, when vim knows modifyOtherKeys is enabled it can use 0x08 only for the backspace key, and Ctrl-h can be a separate mapping.
The problem is that vim thinks modifyOtherKeys is enabled in cases it isn't. Namely because kitty and foot sends CSI u and modifyOtherKeys 1 sequences respectively, without modifyOtherKeys being enabled. I'm not sure how vim can be sure that modifyOtherKeys is enabled though.
This is required, otherwise the mappings that take advantage of the extra information in the key codes cannot work.
Right, I get that now.
If you actually get 0x08 for CTRL-H then somehow the terminal was switched back to old style key codes. It must have been in the advanced mode (modifyOtherKeys or kitty keyboard protocol) at some point, otherwise the modifyOtherKeys flag would not have been set.
See the above paragraphs. In short, it has not been switched back, but vim thinks modifyOtherKeys is enabled when it hasn't.
I haven't checked the details, but most of the codes that kitty sends are the same as modifyOtherKeys. Not when other than the first four modifiers are used. If you want to see what raw codes Vim is actually getting, use ch_logfile(). If you do that very early you might even spot where the code changes.
There are some differences, but with #11364 and #11396 merged the most important keys work as far as I can see. The ones I've seen that still don't work correctly is F1 to F4, keypad enter, print screen, pause break and any key used with the super modifier.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Louis Régnier
So I've hit the issue again with upstream patch.
For the test I've commented out from my .vimrc
" let &t_TI = ''
" let &t_TE = ''
:verbose :map
Seen modifyOtherKeys: true
n K * :Evaluate<CR>
Last set from /usr/share/vim/vim90/pack/dist/opt/termdebug/plugin/termdebug.vim line 890
Q gq
Last set from /etc/vim/vimrc line 28
n \K :call dist#man#PreGetPage(0)<CR>
Last set from /usr/share/vim/vim90/ftplugin/man.vim line 62
x gx <Plug>NetrwBrowseXVis
Last set from /usr/share/vim/vim90/plugin/netrwPlugin.vim line 88
n gx <Plug>NetrwBrowseX
...
n <C-L> <C-W>l
Last set from ~/.vimrc line 96
n <C-K> <C-W>k
Last set from ~/.vimrc line 95
n <C-J> <C-W>j
Last set from ~/.vimrc line 94
n <C-H> <C-W>h
Last set from ~/.vimrc line 93
I've tested the insert mode CTRL-V:
For each combination of CTR-{h,j,kl}
it gives:
CTRL-H behave like backspace when it appears.
You can try disabling it:
let &t_TE = "<Esc>[<u"
And then output it by doing some shell command, e.g. ":!ls".
I've tried this, it doesn't work or I missunderstood.
If you actually get 0x08 for CTRL-H then somehow the terminal was
switched back to old style key codes. It must have been in the advanced
mode (modifyOtherKeys or kitty keyboard protocol) at some point,
otherwise the modifyOtherKeys flag would not have been set.
Keycode looks like this in kitty, it doesn't implement modifyOtherKeys.
Kitty log:
[292 20:33:38.616273] [PARSE ERROR] Unrecognized DCS code: 0x7a
[292 20:33:38.616285] [PARSE ERROR] Unknown CSI code: 'm' with start_modifier: '' and end_modifier: '%' and parameters: '0'
selection cancelled
[292 20:38:04.390664] [PARSE ERROR] The application is trying to use xterm's modifyOtherKeys. This is superseded by the kitty keyboard protocol: https://sw.kovidgoyal.net/kitty/keyboard-protocol/ the application should be updated to use that
Thanks for your help.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Louis Régnier
I've found a manner to always reproduce the issue:
kitty config
kitty_mod super+ctrl
map kitty_mod+minus change_font_size all -2.0
map kitty_mod+equal change_font_size all 0
- enter vim
- split windows vertically
- decrease font_size using kitty shortcut
- make vim windows equal using CTRL-W + ==
- mapping breaks
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
> > Perhaps you execute some shell command that puts kitty in the
> > different mode and does not switch it back to normal? Or worse: Vim
> > gets some keys in the different protocol, switches on
> > modifyOtherKeys, and then the terminal is switched back. Then Vim
> > obviously gets very confused.
>
> No, when I don't set `t_TI` kitty is not switched to a different mode
> xterms modifyOtherKeys). The thing is that by default kitty sends CSI
> u sequences for some keys. E.g. pressing Super-q sends `CSI 113 ; 9
>
> Vim sets `seenModifyOtherKeys` to true when it sees this CSI u
> sequence, which means `0x08` is not triggering the Ctrl-h mapping
> anymore.
>
> I read that the argumentation for sending CSI u sequences for some
> keys by default is so that these keys can be used in applications
> without implementing support for the full kitty keyboard protocol.
sequence if you want to.
I suppose we could avoid setting the modifyOtherKeys flag for those
kitty-specific escape codes. Is it documented somewhere what these
codes are?
I rough guess would be when the modifier code is more than 16.
An xterm can produce shift+alt+ctrl+meta, which is 1 + 1 + 2 + 4 + 8 =
16. We cannot handle this modifier, thus it's probably good to bail out
and pass the escape code as-is.
> > The mappings are not disabled. The mappings are defined for one
> > escape sequence and then the terminal sends something else, which
> > doesn't match and the mapping doesn't trigger.
>
> What I mean by disabled is that at first `0x08` is triggering the
> Ctrl-h mapping, but after `seenModifyOtherKeys` is set to true it does
> not.
(pressing the BS key instead of CTRL-H).
> > When modifyOtherKeys was implemented a lot of effort was put into
> > supporting two codes for a mapping, since we never know for sure
> > when the terminal goes into modifyOtherKeys mode. Once it does, we
> > know we can tell some keys apart that previously produced the same
> > code, and Vim adapts to that. Until a few hours ago you could not
> > actually tell whether Vim has detected a modifyOtherKeys code. I
> > made it show the flag if you use ":verbose map" in patch 9.0.0794.
>
> Right, I read more about it and now understand what it's about. Since
> e.g. 0x08 can be sent by backspace, when vim knows modifyOtherKeys is
> enabled it can use 0x08 only for the backspace key, and Ctrl-h can be
> a separate mapping.
>
> The problem is that vim thinks modifyOtherKeys is enabled in cases it
> isn't. Namely because kitty and foot sends CSI u and modifyOtherKeys 1
> sequences respectively, without modifyOtherKeys being enabled. I'm not
> sure how vim can be sure that modifyOtherKeys is enabled though.
> > I haven't checked the details, but most of the codes that kitty
> > sends are the same as modifyOtherKeys. Not when other than the first
> > four modifiers are used. If you want to see what raw codes Vim is
> > actually getting, use ch_logfile(). If you do that very early you
> > might even spot where the code changes.
>
> There are some differences, but with #11364 and #11396 merged the most
> important keys work as far as I can see. The ones I've seen that still
> don't work correctly is F1 to F4, keypad enter, print screen, pause
> break and any key used with the super modifier.
cannot handle the modifier. Hopefully that makes it work better.
--
An SQL statement walks into a bar. He approaches two tables
and says, "Mind if I join you?"
/// 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 ///
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Louis Régnier
I've just tested patch 9.0.0801
I hit the issue using: super + ;
Seen modifyOtherKeys: true is here
Kitty log:
[292 21:21:11.274422] [PARSE ERROR] Unrecognized DCS code: 0x7a
[292 21:21:11.274429] [PARSE ERROR] Unknown CSI code: 'm' with start_modifier: '' and end_modifier: '%' and parameters: '0'
[292 21:21:22.832566] [PARSE ERROR] The application is trying to use xterm's modifyOtherKeys. This is superseded by the kitty keyboard protocol: https://sw.kovidgoyal.net/kitty/keyboard-protocol/ the application should be updated to use that
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
Wow, that remark from kitty is quite offensive. It should say "we don't like that xterm protocol, we have something else and don't care about any app that doesn't support it".
I suggest you don't use kitty. It's a bad kitty.
I don't think there is anything else to do on the Vim side. I don't have a "super" key thus I can't try out what happens and why the latest patch doesn't help.
I looked into supporting the kitty protocol, but there does not appear to be a proper way to do it.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
Closed #11403 as completed.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Trygve Aaberge
I suppose we could avoid setting the modifyOtherKeys flag for those kitty-specific escape codes. Is it documented somewhere what these codes are?
I rough guess would be when the modifier code is more than 16. An xterm can produce shift+alt+ctrl+meta, which is 1 + 1 + 2 + 4 + 8 = 16.
Unfortunately, in the kitty keyboard protocol the Super modifier is 8, so that won't help. For instance Super-q is CSI 113 ; 9 u. Not setting seenModifyOtherKeys when the modifier is >= 8 would fix it for the super key, would that be acceptable? Since 8 is for meta, which is not common on keyboards anymore, I would think it's rare that this is used and thus not a problem that seenModifyOtherKeys isn't set for it, since it would be set when shift, alt or control is used.
Also, I'm not sure how to bind the meta key when modifyOtherKeys is used, since vim seems to treat both <M-x> and <A-x> bindings as alt key bindings?
Additionally, some keys without modifiers are set. In these cases the key value will be between 57344 and 63743 (unicode private use area), so it would be preferable to not set seenModifyOtherKeys in these cases as well.
We cannot handle this modifier, thus it's probably good to bail out and pass the escape code as-is.
I'll make a patch to avoid the modifyOtherKeys flag being set when we cannot handle the modifier. Hopefully that makes it work better.
You can't just pass the escape code as is. That means that the characters will be individually interpreted which will break things. E.g. since it contains 9u among other things, it would undo 9 times. If you don't handle a CSI sequence, it should be ignored in its entirety, so it doesn't do anything.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Trygve Aaberge
You can't just pass the escape code as is. That means that the characters will be individually interpreted which will break things. E.g. since it contains
9uamong other things, it would undo 9 times. If you don't handle a CSI sequence, it should be ignored in its entirety, so it doesn't do anything.
I meant 17u here (or any higher number), not 9u, since you're only doing this for modifiers >= 16. I just mixed it up since I've been writing 9u earlier.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Trygve Aaberge
You can't just pass the escape code as is. That means that the characters will be individually interpreted which will break things. E.g. since it contains 9u among other things, it would undo 9 times. If you don't handle a CSI sequence, it should be ignored in its entirety, so it doesn't do anything.
I see that unknown CSI codes is passed as-is so they can be mapped, and of course it's great that it can be mapped even though it's not really supported. However, when it's not mapped it causes a problem because parts of the sequence is interpreted individually, which causes e.g. undos to happen as mentioned.
Can't unknown CSI sequences be checked in its entirety for a mapping to avoid this issue? So if the whole sequence of keys is mapped, that is used, but if not it's dropped.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
> > I suppose we could avoid setting the modifyOtherKeys flag for those
> > kitty-specific escape codes. Is it documented somewhere what these
> > codes are?
> >
> > I rough guess would be when the modifier code is more than 16. An
> > xterm can produce shift+alt+ctrl+meta, which is 1 + 1 + 2 + 4 + 8 =
> > 16.
>
> Unfortunately, in the kitty keyboard protocol the Super modifier is 8,
> setting `seenModifyOtherKeys` when the modifier is >= 8 would fix it
> for the super key, would that be acceptable? Since 8 is for meta,
> which is not common on keyboards anymore, I would think it's rare that
> this is used and thus not a problem that `seenModifyOtherKeys` isn't
> set for it, since it would be set when shift, alt or control is used.
backwards compatible with existing implementations. I think the only
way to deal with this is to ignore it.
> Also, I'm not sure how to bind the meta key when modifyOtherKeys is
> used, since vim seems to treat both `<M-x>` and `<A-x>` bindings as
> alt key bindings?
there is no match then Vim falls back to handling the code as if they
are the same. It tries to allow for mapping the codes differently, but
if some terminal sends Alt where Meta is expected, or the other way
around, it still works. Most users don't know the difference between
Alt and Meta anyway. Wasn't Meta some virtual reality thing? :-)
> Additionally, some keys without modifiers are set. In these cases the
> key value will be between 57344 and 63743 (unicode private use area),
> so it would be preferable to not set `seenModifyOtherKeys` in these
> cases as well.
pass a modifeer value of 1, which means no modifier keys were pressed.
I'm afraid that someone intentionally came up with a solution that is
incompatible with existing implementations and doesn't work with
existing apps.
> > We cannot handle this modifier, thus it's probably good to bail out
> > and pass the escape code as-is.
> >
> > I'll make a patch to avoid the modifyOtherKeys flag being set when
> > we cannot handle the modifier. Hopefully that makes it work better.
>
> characters will be individually interpreted which will break things.
> E.g. since it contains `9u` among other things, it would undo 9 times.
> If you don't handle a CSI sequence, it should be ignored in its
> entirety, so it doesn't do anything.
used as its individual bytes, yes. That's perfectly normal and how it
has always worked in Vi and now in Vim.
I'm afraid that the only conclusion I can make at this point is that
kitty intentionally does things differently from existing terminals, and
arrogantly expects every app to implement its own idea of how it should
work. Without providing any support for that. And actually making it
difficult to do it properly (I asked about how to recognize the
termresponse and didn't get an answer). I can only recomment to not use
kitty as it is now.
--
A year spent in artificial intelligence is enough to make one
believe in God.
/// 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 ///
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
> > You can't just pass the escape code as is. That means that the
> > characters will be individually interpreted which will break things.
> > E.g. since it contains 9u among other things, it would undo 9 times.
> > If you don't handle a CSI sequence, it should be ignored in its
> > entirety, so it doesn't do anything.
>
> and of course it's great that it can be mapped even though it's not
> really supported. However, when it's not mapped it causes a problem
> because parts of the sequence is interpreted individually, which
> causes e.g. undos to happen as mentioned.
>
> Can't unknown CSI sequences be checked in its entirety for a mapping
> to avoid this issue? So if the whole sequence of keys is mapped, that
> is used, but if not it's dropped.
something. It would look like a dead key that you can't use.
As I mentioned in another message, this is how it has always worked and
what users are used to. I see no good reason to change it now. Oh,
maybe I should pop up some friendly paperclip that asks you how you
would like to deal with this weird key? Ehm, no.
--
God made machine language; all the rest is the work of man.
/// 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 ///
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Trygve Aaberge
No, this depends on the terminal. Meta and Alt are different, only when there is no match then Vim falls back to handling the code as if they are the same. It tries to allow for mapping the codes differently, but if some terminal sends Alt where Meta is expected, or the other way around, it still works. Most users don't know the difference between Alt and Meta anyway. Wasn't Meta some virtual reality thing? :-)
I meant when modifyOtherKeys is used. This specifies what Meta and Alt should be encoded as, so it should be the same in any terminal where modifyOtherKeys is implemented (correctly). But okay, let's say in xterm to be specific. I tried assigning a key on my keyboard to the Meta modifier, and if I enable modifyOtherKeys in xterm outside of vim I can see that I get CSI 27 ; 3 ; 113 ~ for Alt-q and CSI 27 ; 9 ; 113 ~ for Meta-q. However, if I bind :imap <M-q> Meta-q in vim and press Meta-q in insert mode I see ñ appearing. If I press Alt-q however, I see Meta-q appearing. Also, if I bind :imap <A-q> Alt-q and check the Meta-q binding with :imap <M-q> it says i <M-q> Alt-q.
I see this matches with the documentation too which says "<A-...> same as <M-...>". So it seems these bindings are the same. Is there some other way to bind the meta key, or isn't it possible to use the Meta modifier?
I'm not going to use the Meta modifier, so that's not really important to me, just something I noticed while checking this out. The point was that since the Meta modifier is so rarely used, I don't see what the problem with not setting seenModifyOtherKeys = true for it? Notice that I'm only talking about the variable seenModifyOtherKeys being set. The meta key would still use the modifyOtherKeys CSI handling of course.
I opened a PR so you can see what I mean specifically: #11413
This PR would fix the issue for Kitty. This issue still persists for foot though, since that is a different problem. The problem there is that it sends modifyOtherKeys 1 keys by default, which sets seenModifyOtherKeys, but modifyOtherKeys 2 is not enabled because it's only enabled for the builtin xterm terminfo. So this needs a different solution.
Hmm, it seems the normal way to code a keys is not respected. It should pass a modifeer value of 1, which means no modifier keys were pressed. I'm afraid that someone intentionally came up with a solution that is incompatible with existing implementations and doesn't work with existing apps.
Yes, so modifyOtherKeys and the kitty protocol encode keys without modifiers differently. But support for this was added in #11364, so that works fine now. And seenModifyOtherKeys isn't set for keys without modifiers, so it doesn't matter for what I'm talking about now. The relevance is that if you use these keys with Shift, Ctrl or Alt, seenModifyOtherKeys is set which triggers the issue. This is also fixed with the PR mentioned above.
No, because the user doesn't get a hint that the key is actually doing
something. It would look like a dead key that you can't use.As I mentioned in another message, this is how it has always worked and
what users are used to. I see no good reason to change it now. Oh,
maybe I should pop up some friendly paperclip that asks you how you
would like to deal with this weird key? Ehm, no.
Well, I think it would be easier for a user to understand that a key is mappable and doesn't do anything by default if you set a message in the status-line like "Unknown key pressed. To map this key use ..." rather than just a bunch of random things happening because the characters in the CSI sequence is interpreted individually.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Ramansh Sharma
I am new to this thread but I am facing the problem. Sometimes I press something in my Kitty terminal that makes some of my .vimrc mappings don't work. How do I fix this?
Reading this thread, I think I have to set Seen modifyOtherKeys: true but where/how do I do that?
Thank you.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
start with showing much more information. What version of Vim and what version of kitty. You should first try to update both versions to the latest versions and verify if that already fixes your problem.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Ramansh Sharma
How do I update kitty? Can't find this on its website.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.