vim mis-manages modifyOtherKeys on xterms

Bug #1956062 reported by Douglas Miller
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
vim (Ubuntu)
New
Undecided
Unassigned

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)

Revision history for this message
Douglas Miller (durgadas311) wrote :
Revision history for this message
Douglas Miller (durgadas311) wrote :

I cloned the vim github repo and did a default build (version 8.2.4014), that version of vim does not exhibit any of this odd behavior. Seems likely that either something has fixed this upstream or else Ubuntu 20.04 vim build enables some feature that causes this.

Revision history for this message
Douglas Miller (durgadas311) wrote :

Examining the raw I/O between this new vim and my xterm, I see that the 'r' command is now turning off modifyOtherKeys (and then back on after the replacement character is typed). So, it would appear that there is a fix to this upstream, and Ubuntu vim is just lacking that fix.

As far as use of ^V in a ":s/" search command, it appears that vim is simply properly interpreting "^[[27;5;109~" now, rather than inserting the whole sequence literally.

So, it appears that the version of vim currently in 20.04 is lacking some fixes.

Revision history for this message
Douglas Miller (durgadas311) wrote :

What version of vim is planned for 22.04? Will these fixes be included?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.