[vim/vim] Inserting modifyOtherKeys escape sequences disables ctrl mappings (Issue #10244)
yoshi1123
Steps to reproduce
(I am not sure if ##6794 references the same issue.)
map <c-p> :echo "test"<cr>
map \a �[27;6;70~
Expected behaviour
Then use should print "test".
Instead, the mapping is ignored.
NOTE: exe "map <c-p> :echo 'test'" will however make the mapping work.
The expected behavior happens when using xterm.
Version of Vim
8.2
Environment
Terminal: urxvt
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.
Bram Moolenaar
When I run urxvt, start "vim --clean" then the CTRL-P mapping works just fine.
I don't understand what you do with mapping backslash-a, mapping keys to a terminal code doesn't make sense.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
yoshi1123
Wait my bad. Type \a manually instead of the norm command. Then it should reproduce it.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
lacygoill
MRE:
nnoremap <C-P> <Cmd>echomsg 'test'<CR> nmap <F3> <Esc>[27;6;70~ call feedkeys("\<F3>\<C-P>")
The issue disappears if the 2nd mapping is made non-recursive (there is no reason for it to be recursive anyway).
Here is a log obtained with --log:
==== start log session Thu Apr 21 20:15:39 2022 ====
0.011215 : raw terminal output: "^[[?1049h^[[>4;2m^[[?1h^[=^[[?2004h^[[?1004h"
0.011243 : raw terminal output: "^[[1;24r^[[?12h^[[?12l^[[22;2t"
0.011886 : raw terminal output: "^[[2;1H▽^[[6n"
0.011911 : raw terminal output: "^[[2;1H ^[[3;1H^[Pzz^[\^[[0%m^[[6n"
0.011940 : raw key input: "^[[2;2R"
0.011963 : raw key input: "^[[3;1R"
0.012030 : raw terminal output: "^[[>c"
0.012071 : raw key input: "^[[>85;95;0c"
0.012118 : raw terminal output: "^[[?12$p"
0.012151 : raw terminal output: "^[]10;?^G^[]11;?^G"
0.012180 : raw key input: "^[]10;rgb:3b00/2300/2200^G^[]11;rgb:df00/db00/c300^G"
0.012698 : SafeState: Start triggering
0.013085 : raw terminal output: "^[[10;29Hby Bram Moolenaar et al.^[[11;19HVim is open source and freely distributable^[[13;29HSponsor Vim development!^[[14;18Htype :help sponsor^[[38;5;4m<Enter>^[[m for information ^[[16;18Htype :q^[[38;5;4m<Enter>^[[m to exit ^[[17;18Htype :help^[[38;5;4m<Enter>^[[m or ^[[38;5;4m<F1>^[[m for on-line help^[[18;18Htype :help version8^[[38;5;4m<Enter>^[[m for version info^[]2;[No Name] - VIM^G"
0.013456 : looking for messages on channels
0.013468 : SafeState: back to waiting, triggering SafeStateAgain
1.185473 : raw key input: "^[[13~"
1.185557 : SafeState: reset: ins_typebuf()
1.185590 : SafeState: Start triggering
1.185633 : looking for messages on channels
1.185649 : SafeState: back to waiting, triggering SafeStateAgain
1.957505 : raw key input: "^P"
1.957574 : SafeState: reset: key typed
1.957596 : SafeState: Start triggering
1.957638 : looking for messages on channels
1.957651 : SafeState: back to waiting, triggering SafeStateAgain
3.145409 : raw key input: "Z"
3.145478 : SafeState: reset: key typed
3.145509 : looking for messages on channels
3.353313 : raw key input: "Q"
3.353406 : Exiting...
3.355659 : raw terminal output: "^[[24;1H^[[?2004l^[[>4;m"
3.355703 : raw terminal output: "^[]2;vim -Nu /tmp/vimrc - ~^G"
3.355754 : raw terminal output: "^[[?1004l^[[?2004l^[[?1l^[>"
Does urxvt even support the modifyOtherKeys feature? If not, you might want to disable it:
let &t_TI = ''
let &t_TE = ''
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
yoshi1123
Basically, I am adding this urxvt resources:
URxvt.keysym.C-S-0x46: string:^[[27;6;70~
This is ctrl+shift+f. Now whenever I type ctrl+shift+f, all the control mappings stop working.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
> Basically, I am adding this urxvt resources:
> ```
> URxvt.keysym.C-S-0x46: string:^[[27;6;70~
> ```
> control mappings stop working.
Hmm, maybe don't do that then?
Once Vim sees an escape squence that indicates modifyOtherKeys it
assumes all keys are sent that way. You can't have one key use
modifyOtherKeys and then others don't. It's all or nothing.
--
hundred-and-one symptoms of being an internet addict:
30. Even though you died last week, you've managed to retain OPS on your
favorite IRC channel.
/// 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.
yoshi1123
Perhaps we can make an option to override that default?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
yoshi1123
Why not allow the user to set the value of modifyOtherKeys?
If the user sets this:
let &t_TI = ""
let &t_TE = ""
and then types a <esc>[27;1;1~ (perhaps by accident), then all the control mappings are broken and there seems to be no way to change it back. It seems that vim doesn't honor the value of t_TI.
When modifyOtherKeys is set to 1, then xterm allows extra modifiers to keys, but still allows a functional terminal.
I think by setting modifyOtherKeys to 2 upon any modifyOtherKeys sequence, ignoring whether the user sets modifyOtherKeys to 0 or 1, is not conforming to xterm's proposed standard.
This is why I think its a good idea to allow for either
- honor the user's
t_TIsetting, or - have a vim option, for example,
set modifyOtherKeys = 1.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
> Why not allow the user to set the value of modifyOtherKeys?
>
> If the user sets this:
> ```
> let &t_TI = ""
> let &t_TE = ""
> ```
> and then types a `<esc>[27;1;1~` (perhaps by accident), then all the
> control mappings are broken and there seems to be no way to change it
A user doesn't type that.
The value of t_TI is used, don't see any problem with it.
> When modifyOtherKeys is set to 1, then xterm allows extra modifiers to
> keys, but still allows a functional terminal.
escape sequence is produced by more than one key combination.
> I think by setting modifyOtherKeys to 2 upon any modifyOtherKeys
> sequence, ignoring whether the user sets modifyOtherKeys to 0 or 1, is
> not conforming to xterm's proposed standard.
>
> This is why I think its a good idea to allow for either
> 2) have a vim option, for example, `set modifyOtherKeys = 1`.
It is not a good idea, because it's just a way how a user can break
things. It might seem to work at first, but then some key combinations
will turn out to be confused with others. That is why it was made to
work this way. Also, modifyOtherKeys value 1 just doesn't work. The
only reason it still exists is that removing it would break backwards
compatibility. Only value 2 works.
--
Nothing is fool-proof to a sufficiently talented fool.
/// 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.
yoshi1123
Okay. But what about a terminal conforming to leonerd's proposed 'CSI u' standard, as mentioned above? Perhaps we can either
- disable 'CSI u' sequences and prevent them from triggering modifyOtherKeys value 2 (only use xterm's modifyOtherKey sequences), as this goes against the 'CSI u' proposed standard, and will break any terminal conforming to that proposed standard, or
- conform to the 'CSI u' proposed standard.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
> Okay. But what about a terminal conforming to leonerd's proposed 'CSI
> u' sequences and prevent them from triggering modifyOtherKeys value 2
> (only use xterm's modifyOtherKey sequences), as this goes against the
> 'CSI u' proposed standard, and will break any terminal conforming to
> that proposed standard, or
Both forms are accepted, they don't conflict:
{lead}27;{modifier};{key}~
{lead}{key};{modifier}u
Unfortunately there appear to be multiple opinions about terminal
emulators and there doesn't seem to be a common effort. The solution
often chosen is to make yet another implementation...
--
A fine is a tax for doing wrong. A tax is a fine for doing well.
/// 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.
yoshi1123
The primary motivation of this scheme is to encode any possible keypress uniquely; that a keypress maps to one possible sequence of bytes, and a valid sequence of bytes encodes only one keypress. For backward compability, it is also required that any keypress that can be represented without this scheme is also represented by the same bytes within it; that is, this scheme is an extension of existing encodings, not a replacement of. (https://www.leonerd.org.uk/hacks/fixterms/)
With this standard proposal, 'CSI u', it specifies this key sequence: {lead}{key};{modifier}u.
This is where that key sequence comes from. As quoted above, that standard proposal says that it is an extension, and compatible with traditional encodings. Thus with this standard proposal, any control sequence which already exists (e.g., ctrl+v) is not modified. ctrl+v still sends byte 0x16. However ctrl+shift+v will send ESC[86;6u. According to the standard proposal linked above (the origin, I believe, of {lead}{key};{modifier}u).
In no way does the above standard proposal for {lead}{key};{modifier}u specify that ctrl+v ever send a {lead}{key};{modifier}u sequence. It always sends byte 0x16. This is the same with all traditional control sequences (e.g., ctrl+a, ctrl+b, etc.).
Can you please stop vim from breaking mappings when it sees {lead}{key};{modifier}u, and just use {lead}27;{modifier};{key}~.
I see absolutely no need to use {lead}{key};{modifier}u sequences when there are {lead}27;{modifier};{key}~ sequences available (and Vim does conform to mode 2 of xterm's proposed standard for the {lead}27;{modifier};{key}~ encoding).
I realize you may have created your own implementation here, but this needlessly breaks all of terminal implementations conforming to the 'CSI u' proposed standard.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
Well, isn't the problem here, that Vim is using modifyOtherKeys 2 and you would rather like to have support for the CSI u standard? I think those are not compatible with each other.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
With modifyOtherKeys CTRL-V sends raw key input: "[27;5;118~".
If this is not mapped then it is reduced to CTRL-V 0x16 by Vim and then looking for a matching mapping again.
It could work to have CTRL-V send 0x16, but it won't work for CTRL-I, for example, because then it's equal to a Tab and you can't tell them apart. Trying to make a list of keys that could be confused with another is pointless, since it just makes it more complicated.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.