arrow keys don't move cursor but output ABCD in INSERT mode
Kent
hi guys,
Tim Chase
> last weekend I finally did the switch from .vim to
> vim-addon-manager. after the change, I made some small tests,
> almost everything looks fine. but the arrow key don't move
> cursor in INsert mode any longer, just ouput A, B, C, and D. I
> remembered that could be the vi-compatible problem.
This sounds suspiciously like your terminal is sending an escape
sequence to move the cursor, and that the escape is being eaten.
I'd start by checking your timeouts:
:verbose set tm? ttm? to? ttimeout?
and reading at the documentation for those settings. However,
I'm not sure (1) why it would only be noticed in insert mode
rather than in all modes, nor (2) why switching to the
vim-addon-manager would have triggered the change.
If there's nothing hinky about those timeout settings (responding
with their values and where they were last set would be the next
step), perhaps others on the list would have other ideas.
-tim
Ben Schmidt
> On 07/04/2011 03:07 AM, Kent wrote:
>> last weekend I finally did the switch from .vim to
>> vim-addon-manager. after the change, I made some small tests,
>> almost everything looks fine. but the arrow key don't move
>> cursor in INsert mode any longer, just ouput A, B, C, and D. I
>> remembered that could be the vi-compatible problem.
>
> This sounds suspiciously like your terminal is sending an escape
> sequence to move the cursor, and that the escape is being eaten.
I just realised I'm seeing this, as I pressed an arrow key by mistake (I
never usually use them)!
So this may be a recent regression.
Which Vim versions are you using?
I might try to do a bisect with Mercurial to identify which changeset
introduced the problem anyway.
I don't use vim-addon-manager, so it's not related to that.
Ben.
Ben Schmidt
Hmm. No, I don't think this is it. I tried doing a bisect, but trying to
find a good changeset didn't really work--Vim 7.3.2 has the problem, and
I definitely didn't experience the behaviour that long ago. I get the
problem with -u NONE, so it's not just configuration either. So I don't
know what's causing it yet.
To the OP: what system and Vim version etc. do you use? What Vim
features are compiled in? Probably easiest if you could post your
:version output. Mine is below.
Cheers,
Ben.
VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Jul 7 2011 11:01:12)
MacOS X (unix) version
Included patches: 1-219
Modified by Ben Schmidt et al.
Compiled by b...@thought.local
Huge version with GTK2 GUI. Features included (+) or not (-):
+arabic +autocmd +balloon_eval +browse ++builtin_terms +byte_offset +cindent
+clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments
+conceal +cryptv +cscope +cursorbind +cursorshape +dialog_con_gui +diff
+digraphs +dnd -ebcdic +emacs_tags +eval +ex_extra +extra_search +farsi
+file_in_path +find_in_path +float +folding -footer +fork() -gettext
-hangul_input +iconv +insert_expand +jumplist +keymap +langmap +libcall
+linebreak +lispindent +listcmds +localmap -lua +menu +mksession +modify_fname
+mouse +mouseshape +mouse_dec -mouse_gpm -mouse_jsbterm +mouse_netterm
-mouse_sysmouse +mouse_xterm +multi_byte +multi_lang -mzscheme +netbeans_intg
+path_extra +perl +persistent_undo +postscript +printer +profile +python
-python3 +quickfix +reltime +rightleft +ruby +scrollbind +signs +smartindent
-sniff +startuptime +statusline -sun_workshop +syntax +tag_binary
+tag_old_static -tag_any_white +tcl +terminfo +termresponse +textobjects +title
+toolbar +user_commands +vartabs +vertsplit +virtualedit +visual +visualextra
+viminfo +vreplace +wildignore +wildmenu +windows +writebackup +X11 -xfontset
+xim +xsmp_interact +xterm_clipboard -xterm_save
system vimrc file: "$VIM/vimrc"
user vimrc file: "$HOME/.vimrc"
user exrc file: "$HOME/.exrc"
system gvimrc file: "$VIM/gvimrc"
user gvimrc file: "$HOME/.gvimrc"
system menu file: "$VIMRUNTIME/menu.vim"
fall-back for $VIM: "/usr/local/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -D_REENTRANT
-I/opt/local/include/gtk-2.0 -I/opt/local/lib/gtk-2.0/include
-I/opt/local/include/atk-1.0 -I/opt/local/include/cairo
-I/opt/local/include/gdk-pixbuf-2.0 -I/opt/local/include/pango-1.0
-I/opt/local/include/gio-unix-2.0/ -I/opt/local/include
-I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/include
-I/opt/local/include/pixman-1 -I/opt/local/include/freetype2
-I/opt/local/include/libpng14 -DMACOS_X_UNIX -no-cpp-precomp -g -O2
-D_FORTIFY_SOURCE=1 -I/usr/X11/include
-I/System/Library/Frameworks/Tcl.framework/Headers -D_REENTRANT=1
-D_THREAD_SAFE=1 -D_DARWIN_C_SOURCE=1
Linking: gcc -L/opt/local/lib -L/usr/X11/lib -R/usr/X11/lib -L. -g -o
vim -L/opt/local/lib -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lpangocairo-1.0
-lXext -lXrender -lXinerama -lXi -lXrandr -lXcursor -lXcomposite -lXdamage
-lgdk_pixbuf-2.0 -lpangoft2-1.0 -lgio-2.0 -lXfixes -lcairo -lpng14 -lpango-1.0
-lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lglib-2.0
-lintl -lXt -lX11 -lSM -lICE -lncurses -liconv -framework Cocoa
-L/opt/local/lib -fstack-protector
-L/opt/local/lib/perl5/5.12.3/darwin-multi-2level/CORE -lperl -lm -lutil -lc
-framework Python -F/System/Library/Frameworks -framework Tcl -framework
CoreFoundation -lruby
Benjamin R. Haskell
>
> hi guys,
> last weekend I finally did the switch from .vim to vim-addon-manager.
> after the change, I made some small tests, almost everything looks
> fine. but the arrow key don't move cursor in INsert mode any longer,
> just ouput A, B, C, and D. I remembered that could be the
> vi-compatible problem. So I added
>
> set nocp
>
> in my .vimrc. unfortunately, this didn't help. I open a file, try :set cp ? ,
> "nocompatible" was returned.
>
> In gvim, arrow keys work fine, the problem happens only with vim in terminal.
>
> Do you guys have any idea, where is the problem? please give me a
> hint, thank you!
I'm not sure why it would be related to switching from .vim to VAM, but
this might be a problem with your system's terminfo/termcap libraries.
Maybe the way you've set up VAM no longer sources some systemwide vimrc.
Often distributions work around problems with the arrow keys in
particular by hardcoding sequences into /etc/vimrc (or similar). E.g.
on OpenSUSE, the systemwide startup file has:
if &term =~ "xterm"
let myterm = "xterm"
" ... later in that file ...
if myterm == "xterm" || myterm == "kvt" || myterm == "gnome"
" ...
map <Esc>[A <Up>
map <Esc>[B <Down>
map <Esc>[C <Right>
map <Esc>[D <Left>
So, it's working around a deficiency (which might not even still be
present) of the terminfo files that didn't list the "application mode"
(also called "keypad transmit mode") sequences for the arrow keys.
I don't see any such workarounds in arch's startup file
/usr/share/vim/vimfiles/archlinux.vim (sourced by /etc/vimrc). But I
still think that's the rough outline of where the problem lies.
The reason it works in gvim is that it doesn't use an extra translation
layer that's necessary in (terminal-)vim. It can directly read the keys
that are sent to it. Terminal vim only gets what it can decode.
One way to determine where the problem might occur would be to grep for
OA, OB, OC, OD in some of your own startup files. (Maybe you have
something from long ago that worked around this issue, and the switch
from .vim to VAM bypasses that workaround?)
--
Best,
Ben
Ben Schmidt
> On 6/07/11 11:40 PM, Ben Schmidt wrote:
>> On 4/07/11 10:56 PM, Tim Chase wrote:
>>> On 07/04/2011 03:07 AM, Kent wrote:
>>>> last weekend I finally did the switch from .vim to
>>>> vim-addon-manager. after the change, I made some small tests,
>>>> almost everything looks fine. but the arrow key don't move
>>>> cursor in INsert mode any longer, just ouput A, B, C, and D. I
>>>> remembered that could be the vi-compatible problem.
>>>
>>> This sounds suspiciously like your terminal is sending an escape
>>> sequence to move the cursor, and that the escape is being eaten.
>>
>> I just realised I'm seeing this, as I pressed an arrow key by mistake (I
>> never usually use them)!
>>
>> So this may be a recent regression.
>>
>> Which Vim versions are you using?
>>
>> I might try to do a bisect with Mercurial to identify which changeset
>> introduced the problem anyway.
>
> Hmm. No, I don't think this is it. I tried doing a bisect, but trying to
> find a good changeset didn't really work--Vim 7.3.2 has the problem, and
> I definitely didn't experience the behaviour that long ago. I get the
> problem with -u NONE, so it's not just configuration either. So I don't
> know what's causing it yet.
Making a little progress tracking this down. For me it happens when I
start Vim normally, or with -u NONE or with -N. However, if I use
-u NONE -N (both options together), the problem does not occur.
I'll post again if I make more progress. In the meantime, though, does
that set of switches fix it for others experiencing this problem?
Ben.
Tony Mechelynck
-u NONE:
no vimrc hence 'compatible' mode unless also -N
no gvimrc
no plugins
-N
use 'nocompatible' mode even if no vimrc
neither
use vimrc from usual location if found
'nocompatible' if found, else 'compatible'
in gvim only, use gvimrc from usual location if found
use global plugins from $VIMRUNTIME/plugin/
(and other plugin/ subfolders of 'runtimepath' folders)
'compatible' influences a lot of other options (see :help 'compatible'),
see if your vimrc sets any of those and how (and see also :help :verbose)
Check also near the top of the output of :scriptnames � maybe you
unwittingly have a system vimrc (a vimrc without . or _ in front of its
name, usually in $VIM but on Unix sometimes in /etc/ � the exact
location is displayed about one-third of the way down from the top of
the output of :version)
>
> I'll post again if I make more progress. In the meantime, though, does
> that set of switches fix it for others experiencing this problem?
>
> Ben.
>
>
>
Best regards,
Tony.
--
The people of Halifax invented the trampoline. During the
Victorian period the tripe-dressers of Halifax stretched tripe across a
large wooden frame and jumped up and down on it to `tender and dress'
it. The tripoline, as they called it, degenerated into becoming the
apparatus for a spectator sport.
The people of Halifax also invented the harmonium, a device for
castrating pigs during Sunday service.
-- Mike Harding, "The Armchair Anarchist's Almanac"
Ben Schmidt
Update: In my case, it is the following in my .vimrc that is causing the
problem:
inoremap <expr> <Esc> pumvisible()?"\<C-E>":"\<Esc>"
I added this fairly recently as I started using completion more and
wanted to control the menu differently to how Vim usually does. I
thought it worked, but possibly I only tested in MacVim, not realising
it breaks things in terminal Vim.
No idea how to solve that yet. If anyone has any ideas, please let me
know. Mind you, it probably doesn't matter much: I hadn't noticed it was
broken until I tried it in response to the original post, so I obviously
don't use it much--not at all in the past month or so!
The thing about compatible mode seems to have been a red herring in my
case, but I tracked that down, too. When in compatible mode 'esckeys' is
reset so the arrows don't work. Issuing :set nocp or :set esckeys fixes
it.
Ben.