I generally set both VISUAL
and EDITOR
environment variables to the same thing, but what's the difference? Why would I set them differently? When developing apps, why should I choose to look at VISUAL
before EDITOR
or vice versa?
The EDITOR
editor should be able to work without use of "advanced" terminal functionality (like old ed
or ex
mode of vi
). It was used on teletype terminals.
A VISUAL
editor could be a full screen editor as vi
or emacs
.
E.g. if you invoke an editor through bash (using C-x C-e
), bash will try first VISUAL
editor and then, if VISUAL
fails (because terminal does not support a full-screen editor), it tries EDITOR
.
Nowadays, you can leave EDITOR
unset or set it to vi -e
.
-
8Most applications treat
$VISUAL
as a shell snippet that they append the (shell-quoted) file name to, but some treat it as the name of an executable which they may or may not search in$PATH
. So it's best to setVISUAL
(andEDITOR
) to the full path to an executable (which could be a wrapper script if you want e.g. options). – Gilles Dec 15 '10 at 18:27 -
4In modern times,
ed
and similar are not very popular so I believe it is OK to just ignoreVISUAL
and useEDITOR
. – Pavel Šimerda Mar 30 '14 at 17:35 -
12
-
5@PavelŠimerda, just setting
EDITOR
is not enough e.g. forgit
on Ubuntu 12.04. WithoutVISUAL
being setgit
ignoresEDITOR
and just usesnano
(the compiled in default, I guess). – maxschlepzig Apr 25 '15 at 10:24 -
5@PavelŠimerda It doesn't make sense, but it's the convention. EDITOR used to be for instruction-based editors like
ed
. When editors with GUIs came about--and by GUI, I mean CLI GUI (vim, emacs, etc.--think ncurses), not desktop environment GUI--the editing process changed dramatically, so the need for another variable arose. In this context, CLI GUI and desktop environment GUI editors are more or less the same, so you can set VISUAL to either; however, EDITOR is meant for a fundamentally different workflow. Of course, this is all historical. Nobody uses ed these days. – Zenexer Sep 17 '16 at 22:34
The accepted answer is probably a good, short treatment, but this will be an attempt to go deeper on when the distinction between VISUAL and EDITOR might still matter (possibly building on Adam Katz's answer).
The POSIX spec still distinguishes between visual mode editors and line editors. This really mattered back in the days when cursor positioning over serial connections was hard (especially because of the speed of the serial connection). The Wikipedia article for vi gives some useful background on the distinction between vi (a visual mode editor) and ex (a line editor). If you dig deep enough down the research, you'll find the "RATIONALE" section of the "ex" spec, which gives a reason for the distinction still being in the spec:
It is recognized that portions of vi would be difficult, if not impossible, to implement satisfactorily on a block-mode terminal, or a terminal without any form of cursor addressing, thus it is not a mandatory requirement that such features should work on all terminals. It is the intention, however, that a vi implementation should provide the full set of capabilities on all terminals capable of supporting them.
I haven't needed this since giving up my 300 baud modem, but I can imagine that people who use slow serial lines to connect to embedded systems (and/or over really dicey connections) might still appreciate being able to have a preferred line mode editor distinct from a "visual" editor like vi. VT100-style terminal codes over a lossy, laggy, narrow connection might be "bloat" in limited applications.
For the rest of us, it seems the "correct" answer seems to be "set them both to be your preferred editor". It might be ok to co-opt this distinction for local/graphical editor (e.g. Sublime or gvim) vs a terminal window editor (e.g. vi or emacs), but there's likely a mountain of legacy reasons why that probably won't work as hoped.
Some tools only accept EDITOR, for example the shell builtin fc:
-e ENAME select which editor to use. Default is FCEDIT, then EDITOR, then vi
I've concluded that $VISUAL
is graphical and $EDITOR
is command line. If undefined, anything seeking $VISUAL
should then try $EDITOR
next.
(Citation needed: I'd love to get the proper documentation, perhaps a man page or POSIX spec?)
At the moment, I have stuff like this in my ~/.bashrc
and ~/.zshrc
:
EDITOR="$(command -v vim)"
# we have gvim, not in an SSH term, and the X11 display number is under 10
if command -v gvim >/dev/null 2>&1 \
&& [ "$SSH_TTY$DISPLAY" = "${DISPLAY#*:[1-9][0-9]}" ]; then
export VISUAL="$(command -v gvim) -f"
SUDO_EDITOR="$VISUAL"
else
SUDO_EDITOR="$EDITOR"
fi
gvim
without -f
won't work with programs that expect to act on your edits. This definitely includes sudoeditor
(sudo -e
).
This may break if you have whitespace in the path to vim. If that's a problem, either install it properly or else consider symlinks like /usr/local/bin/gvim
-
Whether to use
$VISUAL
depends whether you have a terminal capable of cursor positioning, not whether you have a window system available. – Radon Rosborough Mar 13 '18 at 23:01 -
Ah, great! Can you provide a definitive reference link for that? I think my code is still safe since I'm also checking for
$DISPLAY
, but that's good to know. – Adam Katz Mar 14 '18 at 14:24 -
Never mind, it appears such a references exists in robla's answer, which even mentions my answer. – Adam Katz Mar 14 '18 at 14:43
Since there don't seem to be any environments where vi or similar would fail, I've taken to setting VISUAL to something that needs an X DISPLAY, and EDITOR to ex.
Mostly, that just seems to cause me problems when some program doesn't use VISUAL.