Public bug reported:
This began as question #700006. I've observed odd behavior in vim since
my upgrade from 18.04 to 20.04. One in particular is when I use the "r"
command to replace a single character, shifted letters fail to work
correctly and vim sputters and changes the case of letters in the line,
instead of replace a single character. Another place is in search
strings where I want to use the carriage-return character and type
Ctrl-V Ctrl-M, the Ctrl-M appears as an ESC sequence instead of "^M" and
the search fails to do what I intended.
Analyzing the problem in question #700006 revealed this:
When vim initializes (the xterm), it sends "^[[>4;2m" which sets the
modifyOtherKeys=2 parameter. This appears to send *any* keys that use
modifiers (Shift, Ctrl, Alt) as ESC sequences, as we've seen. This
explains why the un-shifted keys "r" and "s" appear normally. But, it
appears that there are certain cases where vim is not properly
interpreting the sequences that it requested.
In the case of the "s" command, vim sends an "^[[>4;m"
(modifyOtherKeys=0) before I can type the "A", so the "A" comes in as a
normal ASCII character. It appears that vim should also be doing the
same thing for "r" but does not. There are probably other contexts where
vim is failing to properly manage the modifyOtherKeys setting, such as
when I try ^V^M in search commands.
In the case of the "r" command, vim sends no ESC sequences after the "r"
so the "A" comes in as the ESC sequence "^[[27;2;65~" and confuses vim.
In the case of search commands, vim is also failing to reset the
modifyOtherKeys setting, so the ^V and ^M are sent as ESC sequences -
although it appears that vim recognizes the ^V "^[[27;5;118~" and then
(correctly) ignores the ESC in the ^M sequence "^[[27;5;109~". FYI, I
understand that vim can now recognize "\r" in search strings, but that
still leaves the problem of all the other control characters I must
often manipulate in search commands.
It is looking now as though there is actually a bug in vim, where it
does not properly manage the modifyOtherKeys setting even though it
explicitly requests that setting.
ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: vim 2:8.1.2269-1ubuntu5.4
ProcVersionSignature: Ubuntu 5.4.0-91.102-generic 5.4.151
Uname: Linux 5.4.0-91-generic x86_64
ApportVersion: 2.20.11-0ubuntu27.21
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: ubuntu:GNOME
Date: Thu Dec 30 15:49:03 2021
InstallationDate: Installed on 2017-02-22 (1772 days ago)
InstallationMedia: Ubuntu 16.04.2 LTS "Xenial Xerus" - Release amd64
(20170215.2)
ProcEnviron:
TERM=xterm
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: vim
UpgradeStatus: Upgraded to focal on 2020-10-04 (451 days ago)
** Affects: vim (Ubuntu)
Importance: Undecided
Status: New
** Tags: amd64 apport-bug focal
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to vim in Ubuntu.
https://bugs.launchpad.net/bugs/1956062
Title:
vim mis-manages modifyOtherKeys on xterms
Status in vim package in Ubuntu:
New
Bug description:
This began as question #700006. I've observed odd behavior in vim
since my upgrade from 18.04 to 20.04. One in particular is when I use
the "r" command to replace a single character, shifted letters fail to
work correctly and vim sputters and changes the case of letters in the
line, instead of replace a single character. Another place is in
search strings where I want to use the carriage-return character and
type Ctrl-V Ctrl-M, the Ctrl-M appears as an ESC sequence instead of
"^M" and the search fails to do what I intended.
Analyzing the problem in question #700006 revealed this:
When vim initializes (the xterm), it sends "^[[>4;2m" which sets the
modifyOtherKeys=2 parameter. This appears to send *any* keys that use
modifiers (Shift, Ctrl, Alt) as ESC sequences, as we've seen. This
explains why the un-shifted keys "r" and "s" appear normally. But, it
appears that there are certain cases where vim is not properly
interpreting the sequences that it requested.
In the case of the "s" command, vim sends an "^[[>4;m"
(modifyOtherKeys=0) before I can type the "A", so the "A" comes in as
a normal ASCII character. It appears that vim should also be doing the
same thing for "r" but does not. There are probably other contexts
where vim is failing to properly manage the modifyOtherKeys setting,
such as when I try ^V^M in search commands.
In the case of the "r" command, vim sends no ESC sequences after the
"r" so the "A" comes in as the ESC sequence "^[[27;2;65~" and confuses
vim.
In the case of search commands, vim is also failing to reset the
modifyOtherKeys setting, so the ^V and ^M are sent as ESC sequences -
although it appears that vim recognizes the ^V "^[[27;5;118~" and then
(correctly) ignores the ESC in the ^M sequence "^[[27;5;109~". FYI, I
understand that vim can now recognize "\r" in search strings, but that
still leaves the problem of all the other control characters I must
often manipulate in search commands.
It is looking now as though there is actually a bug in vim, where it
does not properly manage the modifyOtherKeys setting even though it
explicitly requests that setting.
ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: vim 2:8.1.2269-1ubuntu5.4
ProcVersionSignature: Ubuntu 5.4.0-91.102-generic 5.4.151
Uname: Linux 5.4.0-91-generic x86_64
ApportVersion: 2.20.11-0ubuntu27.21
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: ubuntu:GNOME
Date: Thu Dec 30 15:49:03 2021
InstallationDate: Installed on 2017-02-22 (1772 days ago)
InstallationMedia: Ubuntu 16.04.2 LTS "Xenial Xerus" - Release amd64
(20170215.2)
ProcEnviron:
TERM=xterm
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: vim
UpgradeStatus: Upgraded to focal on 2020-10-04 (451 days ago)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/vim/+bug/1956062/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
