[Touch-packages] [Bug 1956062] Re: vim mis-manages modifyOtherKeys on xterms
What version of vim is planned for 22.04? Will these fixes be included? -- 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 #76. 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 #76 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= 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
[Touch-packages] [Bug 1956062] Re: vim mis-manages modifyOtherKeys on xterms
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. -- 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 #76. 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 #76 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= 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
[Touch-packages] [Bug 1956062] Re: vim mis-manages modifyOtherKeys on xterms
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. -- 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 #76. 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 #76 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= 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
