Arrow keys in insert mode in vim

[Chris Sutcliffe]

Hey Andy,

Using svn 556, the arrow keys now print capital letters (i.e. 'A' for
up, 'B' for down, 'C' for right and 'D' for left) instead of moving
the cursor when in insert mode in vim. I take it this has something
to do with the changes to the escape sequences?

Chris

--
Chris Sutcliffe
http://emergedesktop.org

[Chris Sutcliffe]

> Using svn 556, the arrow keys now print capital letters (i.e. 'A' for
> up, 'B' for down, 'C' for right and 'D' for left) instead of moving
> the cursor when in insert mode in vim.  I take it this has something
> to do with the changes to the escape sequences?

Also, the left mouse button click now inserts an 'M'.

[Andy Koppe]

Chris Sutcliffe:

> Using svn 556, the arrow keys now print capital letters (i.e. 'A' for
> up, 'B' for down, 'C' for right and 'D' for left) instead of moving
> the cursor when in insert mode in vim.

I think that's always been like that. Same in rxvt anyway. The arrow
keys send codes like '\eOA' and '\eOB', so vim is treating the last
letter separately for some reason. Presumably something to do with
vim's keycode timeout settings, but you'd have a better idea which of
the various settings in that area needs adjusting.

Strangely, 'set mouse=a' makes the issue go away.

> I take it this has something to do with the changes to the escape sequences?

No, the cursor key codes haven't changed; they're still standard
"application cursor key" codes.

What has changed is that the mousewheel now simply sends up/down
cursor key codes as well (unless "Scrollback on alternate screen is
on").

> Also, the left mouse button click now inserts an 'M'.

That I cannot reproduce. 'M' is part of the xterm mouse reporting
sequence though, so it might be another timeout issue: "On button
press, xterm sends CSI M C b C x C y (6 characters). C b is button-1.
C x and C y are the x and y coordinates of the mouse when the button
was pressed."

Andy

[Chris Sutcliffe]

My bad...

> That I cannot reproduce. 'M' is part of the xterm mouse reporting
> sequence though, so it might be another timeout issue: "On button
> press, xterm sends CSI M C b C x C y (6 characters). C b is button-1.
> C x and C y are the x and y coordinates of the mouse when the button
> was pressed."

Both issue were related to ttimeoutlen being set to 50. I had
reverted to that method because I was intermittently having issues
with mode-dependent cursor method, in that extraneous '[' would be
inserted occasionally when hitting escape to get out of insert mode.
I couldn't reliably reproduce the issue so I didn't bother reporting
it.

I've changed back to the mode-dependent cursor method, and if I manage
to reliably reproduce the issues I'll report it.

Cheers!

[Chris Sutcliffe]

> Both issue were related to ttimeoutlen being set to 50.  I had
> reverted to that method because I was intermittently having issues
> with mode-dependent cursor method, in that extraneous '[' would be
> inserted occasionally when hitting escape to get out of insert mode.
> I couldn't reliably reproduce the issue so I didn't bother reporting
> it.
>
> I've changed back to the mode-dependent cursor method, and if I manage
> to reliably reproduce the issues I'll report it.

I can reproduce the issue:
- switch to insert mode and use the arrow keys to move up
- keep moving up such that vim scrolls the screen contents (I tested
so that it scrolled the screen contents up 30 lines)
- Hit escape to try and leave insert mode
- Instead of leaving insert a '[' is inserted as a new line in to the file

[Andy Koppe]

Chris Sutcliffe:

> I can reproduce the issue:
> - switch to insert mode and use the arrow keys to move up
> - keep moving up such that vim scrolls the screen contents (I tested
> so that it scrolled the screen contents up 30 lines)
> - Hit escape to try and leave insert mode
> - Instead of leaving insert a '[' is inserted as a new line in to the file

Yet another vim timeout issue, I'm afraid. Mintty simply sends '\eO['
down the line when Esc is pressed with "application escape mode"
enabled, so for some reason that gets split up. I'll need to enroll in
vim studies again to try and work out the appropriate settings.

Andy

[Chris Sutcliffe]

Hey Andy,

> Yet another vim timeout issue, I'm afraid. Mintty simply sends '\eO['
> down the line when Esc is pressed with "application escape mode"
> enabled, so for some reason that gets split up. I'll need to enroll in
> vim studies again to try and work out the appropriate settings.

Hrm... it never occurred to me that it could be a timeout. I've
corrected the issue with:

set notimeout

I haven't experienced any negative side effects as of yet.

Cheers!

[Chris Sutcliffe]

Well, it turns out:

> Hrm... it never occurred to me that it could be a timeout.  I've
> corrected the issue with:
>
> set notimeout

Causes other problems if you want to escape out of a multi-key map.
As a result, the best I've come up with to date is:

let &t_SI.="\e[5 q"
let &t_EI.="\e[1 q"
let &t_ti.="\e[1 q\e[?7727h"
let &t_te.="\e[0 q\e[?7727l"
noremap O[ <NOP>
noremap <Esc>O[ <Esc>
noremap! <Esc>O[ <Esc>

The:

noremap O[ <NOP>

Seems to take care of the extraneous '[' being inserted in the line
above where you hit escape.

[pamplemo...@gmail.com]

Hello,

I post an answer for anyone still facing this problem today. The following tip fixes the bug for me:

Try typing this … it fixes it for me:

:set nocompatible

Or, add the line:

set nocompatible

to your ~/.vimrc file.

See http://linuxblog.pansapiens.com/2007/10/31/fixing-the-arrow-keys-in-vim/

[Andy Koppe]

On Nov 21, 5:42 pm, pamplemousse....@gmail.com wrote:
> Hello,
>
> I post an answer for anyone still facing this problem today. The following
> tip fixes the bug for me:
>
> Try typing this … it fixes it for me:
>
> :set nocompatible
>
> Or, add the line:
>
> set nocompatible
>
> to your ~/.vimrc file.

Just the presence of a ~/.vimrc file disables compatibility mode
actually, so it doesn't even have to say 'set nocompatible'.

Andy