Wikia

Vim Tips Wiki

Changes: Fix broken arrow key navigation in insert mode

Edit

Back to page

(Undo revision 30668 by 93.220.111.210 (talk) the colon is helpful; it can be omitted if in vimrc but is useful in tip)
(Change <tt> to <code>, perhaps also minor tweak.)
Line 3: Line 3:
 
|previous=1289
 
|previous=1289
 
|next=1291
 
|next=1291
|created=July 26, 2006
+
|created=2006
 
|complexity=basic
 
|complexity=basic
 
|author=Kim Schulz
 
|author=Kim Schulz
Line 23: Line 23:
   
 
==Comments==
 
==Comments==
I have almost the same problem... By the upgrade was to 7.1, and the effect was that for xterm's left and right arrows would jump from word to word!!!
+
I have almost the same problem... By the upgrade was to 7.1, and the effect was that for xterm's left and right arrows would jump from word to word!!!
   
 
Changing the "t_kl" and "t_kr" mapping (which was incorrect) to anything else had no effect on this. Only changing the "term" setting to either "ansi" or "builtin_ansi" fixed the problem.
 
Changing the "t_kl" and "t_kr" mapping (which was incorrect) to anything else had no effect on this. Only changing the "term" setting to either "ansi" or "builtin_ansi" fixed the problem.
   
Unfortunately changing terminal, breaks the use of function keys, and the use of an alternate editing display in xterms. That is editing will overwrite the previous command output.
+
Unfortunately changing terminal, breaks the use of function keys, and the use of an alternate editing display in xterms. That is editing will overwrite the previous command output.
   
 
HELP?
 
HELP?
Line 33: Line 33:
   
 
* This seems to be a [http://bugs.gentoo.org/212546 bug in vim] --[[Special:Contributions/219.97.14.230|219.97.14.230]] 08:39, 20 February 2009 (UTC)
 
* This seems to be a [http://bugs.gentoo.org/212546 bug in vim] --[[Special:Contributions/219.97.14.230|219.97.14.230]] 08:39, 20 February 2009 (UTC)
** A bug in Vim? Hm, rather, this kind of behaviour is usually due to termcap/terminfo settings not corresponding to what the keyboard is sending or the display accepting. If the installed termcap/terminfo is "better" than the one of the same name built into Vim you can cure the problem by means of <tt>:set nottybuiltin</tt> &#8212; but more often the $TERM environment variable is set to the name of a termcap/terminfo entry not corresponding to the actual terminal in use and that's the culprit. Since I'm on SuSE and not on gentoo I cannot tell which case applies here. &#8212; [[User:Tonymec|Tonymec]] 17:54, 20 February 2009 (UTC)
+
** A bug in Vim? Hm, rather, this kind of behaviour is usually due to termcap/terminfo settings not corresponding to what the keyboard is sending or the display accepting. If the installed termcap/terminfo is "better" than the one of the same name built into Vim you can cure the problem by means of <code>:set nottybuiltin</code> &#8212; but more often the $TERM environment variable is set to the name of a termcap/terminfo entry not corresponding to the actual terminal in use and that's the culprit. Since I'm on SuSE and not on gentoo I cannot tell which case applies here. &#8212; [[User:Tonymec|Tonymec]] 17:54, 20 February 2009 (UTC)
** &#8212; Oh, another thing: it may be due to <tt>'ttimeoutlen'</tt> being set to its default of -1 which means that Vim won't see the difference between mappings and multibyte keycodes. I recommend settings similar to <pre> :set timeout ttimeoutlen=100 timeoutlen=5000</pre> i.e., a <tt>'ttimeoutlen'</tt> faster than you can type (for keycodes) and a <tt>'timeoutlen'</tt> slower than you will usually type (for mappings). (Both timeouts are in milliseconds.) &#8212; [[User:Tonymec|Tonymec]] 18:06, 20 February 2009 (UTC)
+
** &#8212; Oh, another thing: it may be due to <code>'ttimeoutlen'</code> being set to its default of -1 which means that Vim won't see the difference between mappings and multibyte keycodes. I recommend settings similar to <pre> :set timeout ttimeoutlen=100 timeoutlen=5000</pre> i.e., a <code>'ttimeoutlen'</code> faster than you can type (for keycodes) and a <code>'timeoutlen'</code> slower than you will usually type (for mappings). (Both timeouts are in milliseconds.) &#8212; [[User:Tonymec|Tonymec]] 18:06, 20 February 2009 (UTC)
 
** '''&#8212; STOP PRESS &#8212; STOP PRESS &#8212; STOP PRESS &#8212;'''<BR>According to [http://bugs.gentoo.org/212546#c17 comments #17 to #19 in the above-mentioned bug report], "starting gentoo xterm with -kt vt220 makes Vim happy". &#8212; [[User:Tonymec|Tonymec]] 18:23, 20 February 2009 (UTC)
 
** '''&#8212; STOP PRESS &#8212; STOP PRESS &#8212; STOP PRESS &#8212;'''<BR>According to [http://bugs.gentoo.org/212546#c17 comments #17 to #19 in the above-mentioned bug report], "starting gentoo xterm with -kt vt220 makes Vim happy". &#8212; [[User:Tonymec|Tonymec]] 18:23, 20 February 2009 (UTC)
*I had a problem with broken keys when doing ssh on remote servers. None of above tips helped me. But I figured out that doing:<pre>:set nocompatible</pre>resolved my problem. [[User:Rafal Rusin|Rafal Rusin]] 11:24, 10 October 2009
+
*I had a problem with broken keys when doing ssh on remote servers. None of above tips helped me. But I figured out that doing:<pre>:set nocompatible</pre>resolved my problem. [[User:Rafal Rusin|Rafal Rusin]] 11:24, 10 October 2009

Revision as of 06:18, July 13, 2012

Tip 1290 Printable Monobook Previous Next

created 2006 · complexity basic · author Kim Schulz · version n/a


After I upgraded to Vim 7, I had problems when using the arrow keys for navigation in insert mode. The problem was the classic one where lines with A, B or D were inserted when I used the arrows.

The problem only showed up in Vim console mode and not in gvim so I thought that the problem might be in the terminal settings.

That assumption was correct and a single command fixed the problem:

:set term=builtin_ansi

Now the arrowkeys worked again. I guess that all of the builtin term types will work and even some others. Mine was set to xterm which did not work.

Comments

I have almost the same problem... By the upgrade was to 7.1, and the effect was that for xterm's left and right arrows would jump from word to word!!!

Changing the "t_kl" and "t_kr" mapping (which was incorrect) to anything else had no effect on this. Only changing the "term" setting to either "ansi" or "builtin_ansi" fixed the problem.

Unfortunately changing terminal, breaks the use of function keys, and the use of an alternate editing display in xterms. That is editing will overwrite the previous command output.

HELP? Anthony@griffith.edu.au

  • This seems to be a bug in vim --219.97.14.230 08:39, 20 February 2009 (UTC)
    • A bug in Vim? Hm, rather, this kind of behaviour is usually due to termcap/terminfo settings not corresponding to what the keyboard is sending or the display accepting. If the installed termcap/terminfo is "better" than the one of the same name built into Vim you can cure the problem by means of :set nottybuiltin — but more often the $TERM environment variable is set to the name of a termcap/terminfo entry not corresponding to the actual terminal in use and that's the culprit. Since I'm on SuSE and not on gentoo I cannot tell which case applies here. — Tonymec 17:54, 20 February 2009 (UTC)
    • — Oh, another thing: it may be due to 'ttimeoutlen' being set to its default of -1 which means that Vim won't see the difference between mappings and multibyte keycodes. I recommend settings similar to
       :set timeout ttimeoutlen=100 timeoutlen=5000
      i.e., a 'ttimeoutlen' faster than you can type (for keycodes) and a 'timeoutlen' slower than you will usually type (for mappings). (Both timeouts are in milliseconds.) — Tonymec 18:06, 20 February 2009 (UTC)
    • — STOP PRESS — STOP PRESS — STOP PRESS —
      According to comments #17 to #19 in the above-mentioned bug report, "starting gentoo xterm with -kt vt220 makes Vim happy". — Tonymec 18:23, 20 February 2009 (UTC)
  • I had a problem with broken keys when doing ssh on remote servers. None of above tips helped me. But I figured out that doing:
    :set nocompatible
    resolved my problem. Rafal Rusin 11:24, 10 October 2009

Around Wikia's network

Random Wiki