| 2007-03-04 13:27:37 |
robinharvey |
bug |
|
|
added bug |
| 2007-03-05 20:40:24 |
Brian Murray |
vim: status |
Unconfirmed |
Needs Info |
|
| 2007-03-05 20:40:24 |
Brian Murray |
vim: assignee |
|
brian-murray |
|
| 2007-03-05 20:40:24 |
Brian Murray |
vim: statusexplanation |
|
Thanks for taking the time to report this bug and helping to make Ubuntu better. I have been unable to reproduce this bug using vim version 7.0-164+1ubuntu6. What version do you have installed? Thanks in advance. |
|
| 2007-04-04 18:41:02 |
Brian Murray |
vim: status |
Needs Info |
Confirmed |
|
| 2007-04-04 18:41:02 |
Brian Murray |
vim: assignee |
brian-murray |
|
|
| 2007-04-04 18:41:02 |
Brian Murray |
vim: statusexplanation |
Thanks for taking the time to report this bug and helping to make Ubuntu better. I have been unable to reproduce this bug using vim version 7.0-164+1ubuntu6. What version do you have installed? Thanks in advance. |
|
|
| 2007-06-03 20:11:04 |
Steven Garrity |
bug |
|
|
assigned to vim (Fedora) |
| 2007-06-03 21:44:48 |
Steven Garrity |
bug |
|
|
assigned to gnome-terminal (upstream) |
| 2007-06-04 07:40:10 |
Bug Watch Updater |
gnome-terminal: status |
Unknown |
Unconfirmed |
|
| 2007-06-05 07:52:56 |
Bug Watch Updater |
gnome-terminal: status |
Unconfirmed |
Confirmed |
|
| 2007-06-12 23:30:01 |
Micah Cowan |
vim: statusexplanation |
|
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).
|
|
| 2007-06-12 23:32:09 |
Micah Cowan |
title |
cursor control regression in vim |
control-cursor-key regression in vim |
|
| 2007-06-21 15:13:12 |
Sebastien Bacher |
vte: importance |
Undecided |
Low |
|
| 2007-06-21 15:13:12 |
Sebastien Bacher |
vte: assignee |
|
desktop-bugs |
|
| 2007-06-21 15:13:12 |
Sebastien Bacher |
vte: statusexplanation |
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).
|
|
|
| 2007-08-28 22:00:50 |
Sebastien Bacher |
bug |
|
|
assigned to feisty-backports |
| 2007-11-17 03:45:53 |
John Dong |
feisty-backports: status |
New |
Invalid |
|
| 2008-11-30 04:48:53 |
Bug Watch Updater |
gnome-terminal: status |
Confirmed |
Invalid |
|
| 2008-12-01 18:02:10 |
Pedro Villavicencio |
feisty-backports: status |
Invalid |
New |
|
| 2008-12-01 18:02:10 |
Pedro Villavicencio |
feisty-backports: statusexplanation |
I don't think this is a backports suitable bug. It should be handled via a SRU. |
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. |
|
| 2008-12-01 18:02:27 |
Pedro Villavicencio |
marked as duplicate |
|
96676 |
|
| 2009-04-16 19:36:14 |
Steven Garrity |
removed subscriber Steven Garrity |
|
|
|
| 2011-04-13 12:14:50 |
Wagner Macedo |
bug |
|
|
added subscriber wagnerluis1982 |
| 2011-09-09 18:34:59 |
Launchpad Janitor |
vim (Ubuntu): status |
New |
Confirmed |
|
