After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 418732 - problems with vim and shortcuts
problems with vim and shortcuts
Status: RESOLVED DUPLICATE of bug 425462
Product: vte
Classification: Core
Component: general
unspecified
Other All
: Normal normal
: ---
Assigned To: VTE Maintainers
VTE Maintainers
Depends on:
Blocks:
 
 
Reported: 2007-03-15 21:09 UTC by Thilo Six
Modified: 2011-04-13 15:00 UTC
See Also:
GNOME target: ---
GNOME version: 2.17/2.18



Description Thilo Six 2007-03-15 21:09:32 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
Comment 1 Thomas Zajic 2007-03-17 18:40:50 UTC
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.
Comment 2 Thomas Zajic 2007-03-17 19:01:14 UTC
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]:~$ 
Comment 3 Christian Lohmaier 2007-03-20 22:44:36 UTC
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) :-(
Comment 4 Sven Herzberg 2007-06-04 10:29:49 UTC
Same for me...
Comment 5 Thomas Zajic 2007-06-11 07:14:46 UTC
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 ... :-/
Comment 6 Micah Cowan 2007-06-12 23:53:27 UTC
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.
Comment 7 Steven Garrity 2007-08-26 22:07:47 UTC
This seems to work for me now. Fixed?
Comment 8 Thomas Zajic 2007-08-27 05:45:38 UTC
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! :-)
Comment 10 Thilo Six 2007-09-02 11:49:35 UTC
...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.
Comment 11 Behdad Esfahbod 2008-11-29 08:20:25 UTC
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 ***