17

I know that in vim I can add

set nocompatible

in .vimrc to avoid that arrow keys display A, B, C, D in insert mode.

But I'm using vi Version 4.0 (gritter) 12/25/06.

How can I obtain the same behavior?

== EDIT == (1)

I'm using the vi version from Arch Linux which is built from this CVS repository (last commit 24 February 2007) with the following command:

make PREFIX=/usr LIBEXECDIR=/usr/lib/ex PRESERVEDIR=/var/lib/ex \
TERMLIB=ncurses FEATURES="-DCHDIR -DFASTTAG -DUCVISUAL -DMB -DBIT8"

and with theses three patches: fix-tubesize-short-overflow.patch, navkeys.patch and preserve-dir.patch.

== EDIT (2)==

The problems happens in LXTerminal 0.2.0, Termite 10-1, Tilda 1.2.4-1, Terminator 0.98-1 and xterm 320-2 but not in urxvt v9.21 nor in the Linux virtual consoles.

== EDIT (3)==

According to the Single Unix Specification left-arrow, down-arrow, right-arrow, up-arrow correspond to respectively the following capname : kcub1, kcud1, kcuf1 and kcuu1. Comparing terminfo entries from xterm and rxvt-unicode-256color for these capterms gives:

$ infocmp xterm rxvt-unicode-256color | grep -E 'kcuf1|kcub1|kcud1|kcuu1'

kcub1: '\EOD', '\E[D'.
kcud1: '\EOB', '\E[B'.
kcuf1: '\EOC', '\E[C'.
kcuu1: '\EOA', '\E[A'.

Modifying the xterm terminfo entry by substituing '\EOD', '\EOB', '\EOC', '\EOA' by '\E[D', '\E[B', '\E[C', '\E[A' should solve the problem but is it a good idea? Maybe it will break other programs arrow keys usage?

6
  • 2
    I think this is caused by vi(m) <-> terminal interaction, so you can also try some terminal-related workarounds/configuration.
    – VanLaser
    Oct 15, 2015 at 16:05
  • 1
    Translation of what @VanLaser said above: your entry for the current TERM in the termcap or terminfo databases is out of synch with the codes produced by the keyboard. The solution is not to change the TERM, but to find out if your vi is linked against termcap or terminfo, find the keycodes emitted by the keyboard, and fix the corresponding database accordingly. Complaining to the sysadmin might work, too. Oct 15, 2015 at 16:47
  • 1
    Did I say all that? Sometimes I amaze myself :) (of course, all I knew was that it's terminal related).
    – VanLaser
    Oct 15, 2015 at 18:18
  • 1
    This version of vi is built with ncurses, it should then use terminfo. Oct 15, 2015 at 21:28
  • 2
    Did you see these tips? Maybe something of them can be useful. Feb 3, 2016 at 18:09

3 Answers 3

2

You could create an alias that sets your $TERM variable

alias vi='TERM=rxvt-unicode-256color vi'

Add that to your shell's rc file and it should be defined for every terminal you launch.

1
  • 1
    On my system this will just make Vi leave insert mode (which is probably better than having it print garbage, but still doesn't quite fix the issue). Apr 22, 2017 at 8:13
1

Sometimes such behaviour can result from unusual key mappings setup in your .vimrc - so for example if you have something that maps two ESC key presses:

nmap <Esc><Esc> some_command_sequence

Then it can lead to vim malfunctioning with the arrow keys.

1
  • The configuration described by the OP is quite specific, and it displays the behaviour without such a mapping being in place. (I've tested it.)
    – Rich
    Sep 26, 2019 at 14:24
0

The true fix is to use Command mode for movement, not Insert mode. The behavior you are seeing is not a bug, but proper vi/POSIX behavior. You are trying to change something you are telling it to do on purpose.

You are telling vi to Insert the characters represented by the arrow keys, so it does.

Press ESC to get back into Command mode and then you can probably use the arrow keys as desired, including the count functions. Using a modal editor like vi as if it is Windows notepad (mode-less) will never teach you the power and flexibility of vi.

If you don't want to learn vi, then maybe consider nano or mg / emacs. They are mode-less also.

1
  • 3
    Welcome to Vi and Vim! The core of the answer is great: use Normal mode to move around. I think it could do without all the scare-quotes/"you're doing it wrong" attitude. It's fine to suggest there are better ways, but consider how you word it. Just my 2 cents.
    – D. Ben Knoble
    Mar 21, 2021 at 16:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.