GNOME Bugzilla – Bug 418732
problems with vim and shortcuts
Last modified: 2011-04-13 15:00:29 UTC
Please describe the problem: I have vim-full installed: $ aptitude show vim-full Package: vim-full State: installed Automatically installed: no Version: 1:7.0-164+1ubuntu6 In my .vimrc i have the following keymapping: <-------------------------------------------------------- " The paste option is intended for invoking temporarily while pasting in text. " It avoids things like autoindent causing "stepped" text. This defines the " \tp ("toggle paste") mapping, also set to <S-F4> in both normal and insert " mode: nnoremap \tp :set invpaste paste?<CR> nmap <S-F4> \tp imap <S-F4> <C-O>\tp set pastetoggle=<S-F4> --------------------------------------------------------> But instead of setting vim into paste mode it enters "1;2S" at cursor position. After playing a little i found out: <S-F5><S-F6><S-F7><S-F8><S-F9><S-F11><S-F12> These work as expected. But shift+F1 produces 1;2P shift+F2 produces 1;2Q shift+F3 produces 1;2R shift+F4 produces 1;2S when i set the shortcut from <S-F4> to <F4> it works as expected in konsole (kde) everything works as desired. even konsole opened inside gnome does it right. Steps to reproduce: 1. open vim inside gnome-terminal 2. try to use a shortcut in vim e.g. <S-F4> 3. Actual results: it enters "1;2S" at cursor position instead of setting vim into paste mode Expected results: it should put vim into "paste mode" Does this happen every time? yes Other information: originally reported in ubuntu. see original bugreport at: https://launchpad.net/ubuntu/+source/vim/+bug/91468
Similar (same?) problem here using mc (midnight commander) and C-Left/Right (assigned to word-left/right in bash/libreadline), both in the mc panels and in mcedit. C-Left prints "1;5D", C-Right prints "1;5C". Version info: vte-0.16.0, gnome-terminal-2.18.0, mc-4.6.1.
Some more info: C-Left/Right works fine in plain bash (and also in mc's subshell that can be toggled with C-o). Pressing C-v C-Left/Right shows that the proper escape sequences are generated: [zlatko@disclosure]:~$ ^[[1;5D # C-v C-Left [zlatko@disclosure]:~$ ^[[1;5C # C-v C-Right [zlatko@disclosure]:~$ grep -A4 xterm /etc/inputrc # for xterm "\eOH": beginning-of-line "\eOF": end-of-line "\e[1;5C": forward-word "\e[1;5D": backward-word [zlatko@disclosure]:~$
I'm experiencing the same problem. vim in xterm: <ctrl>+v, <ctrl>+<left> produces: ^[[1;5D vim in gnome-termnial, doing the same yields: ^[O1;5D (similar for other combinations and for combinations with <shift>) This is esp. annoying since it doesn't only break navigation, but instead causes insertion of a new line with "1;5D" when one tries to use it. Having to get rid of these insertions is tedious, esp. when you're used to using these combos (and thus have lot of those insertions) :-(
Same for me...
Could this be somehow related to bug #375112 (vte)? Anyway, this annoying problem is still alive and kicking with gnome-terminal-2.18.0 and vte-0.16.5 ... :-/
Breaking with historical practice, xterm practice, and application expectations (such as vim's), vte is now emitting "ESC O 1 ; 5 X" sequences (where X is one of A, B, C, or D) for control-cursor-key combos when "keyboard transmit" mode is in effect. It still issues "ESC [ 1 ; 5 X" when that mode is off. xterm always sends "ESC [ 1 ; 5 X", regardless of whether keyboard transmit mode is on. (Copied from my comment on the launchpad bug [NOTE: in the comment below I refer to "keyboard transmit" mode as "keypad send mode":) Compare the following commands; after each command I am typing as input, a line consisting of <up><down><right><left>, followed by a line of the same keys with the control key held down, followed by Control-D (to terminate input to cat). Here's how it looks in xterm: schmendrick$ cat > /dev/null ^[[A^[[B^[[C^[[D ^[[1;5A^[[1;5C^[[1;5B^[[1;5D schmendrick$ tput smkx; cat > /dev/null; tput rmkx ^[OA^[OB^[OC^[OD ^[[1;5A^[[1;5B^[[1;5C^[[1;5D The "tput smkx" command places the terminal into "keypad send mode"; the second tput command resets that mode. Note that while the normal cursor keys emit different sequences in the two different modes, the control-cursor-keys emit exactly the same sequences. Here's the same thing as it looks in gnome-terminal and xfce4-terminal: schmendrick$ cat > /dev/null ^[[A^[[B^[[C^[[D ^[[1;5A^[[1;5B^[[1;5C^[[1;5D schmendrick$ tput smkx; cat > /dev/null; tput rmkx ^[OA^[OB^[OC^[OD ^[O1;5A^[O1;5B^[O1;5C^[O1;5D --------------- end comment copy/paste --------------- Note that there is no way for applications to understand this change in behavior, and no way for gnome-terminal to communicate this change to applications. Note, too, that unlike xterm's version or the version that vte sends with "keyboard transmit" mode turned off, "ESC O 1 ; 5 X" is not a valid control sequence as defined by ECMA-035/ISO-6429. Neither is "ESC O X" (used for normal cursor keys in keyboard transmit mode by both xterm and vte); but it's at least historical practice, and documented via the termcap/terminfo databases; and understood to be limited to a three-byte sequence.
This seems to work for me now. Fixed?
Same here, but I forgot to report back here ... sorry. :-/ Seems like it was a vte bug after all, as gnome-terminal-2.18.1 didn't fix it, but the latest vte-0.16.8 did - yeah! Upgrading to vte-0.16.8 brought back the Ctrl+Up/Down/Left/Right functionality in mc immediately, and the Shift-Fn function keys also worked again after relearning them in mc (F9 -> Options -> Learn Keys). Big thanks to whoever found and fixed that annoying bug - gnome-terminal is now finally usable again with mc! :-)
https://bugs.launchpad.net/ubuntu/+source/gnome-terminal/+bug/91468/comments/16
...but i do not know if that´s a breakage in those packages provided or still a bug in vte 0.16.8 but it´s not solved for me.
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of 425462 ***