Comment 18 for bug 89660

Revision history for this message
Micah Cowan (micahcowan) wrote : Re: cursor control regression in vim

It seems extremely likely to me that this is a bug with vte, rather than vim, so I'm reassigning.

vim is expecting the same sequences it has always expected from xterm and xterm-emulating ttys.
xterm normally sends ESC [ A for <cursor up>; when "keypad send mode" is on (vim activates this mode), it sends ESC O A instead. Regardless of mode, <control-cursor-up> is represented as ESC [ 1 ; 5 A.

gnome-terminal and xfce4-terminal (both of which use vte to handle terminal emulation), are currently sending erroneous codes for <control-cursor-up> (and others) when "keypad send mode" is on: ESC O 1 ; 5 A (which is not a valid sequence). vim doesn't recognize it, and interprets it directly, which means it is interpreted as "end input mode; open a new line above current position; start inserting 1;5A...".

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

Note that for both the normal cursor keys and the control-cursor-key combos, the "[" character in the sequence is replaced with an "O". This is more consistent, but it breaks with previous behavior, and xterm's behavior, and there is no way for vim to understand how to process these sequences (other than as literal vim commands, which is what you've seen).