In Unix-like systems, you’ll see two environment variables frequently associated with text editing: VISUAL and EDITOR. At first glance, they look interchangeable — you’ll often see them both set to the same editor. Historically, though, there’s a reason they exist separately, and in certain environments today you may still benefit from giving them different values.

Historical Context

Line Editors vs Visual Editors

Very early terminals had no cursor-positioning features. So editors (such as ed and ex) were command-based “line editors”. Users would edit files by typing commands rather than visually navigating around a file.

Over time, terminals gained cursor-positioning features, and more advanced “visual mode” editors emerged (such as vi, emacs, and nano) that also supported cursor-positioning features. This meant users could now move around text in real time in an interactive TUI, using arrow keys and on-screen updates.

TUI stands for “terminal user interface” and refers to an interactive interface similar to a GUI (“graphical user interface”), but only within the terminal.

The roles of VISUAL and EDITOR environment variables

Traditionally, EDITOR refers to a simpler, possibly line-based editor — or any generic “fallback” editor and VISUAL refers to a more interactive, full-screen “visual” terminal editor, like the ones we commonly use today. For this reason, modern tools (e.g., Git) check VISUAL first. If VISUAL is unset, they fall back to EDITOR. If both are unset, the system or tool may default to something like vi.

Today, these environment variables are usually the same modern terminal editor, such as vim, nvim, or nano. This works perfectly fine for almost all cases nowadays, unless you still need a line-editor for a specialised use case, such as editing over an extremely limited terminal (like ancient teletype or extremely slow serial connections).

Do you need to set both?

: In most modern situations, simply setting both to your favourite modern editor will be perfectly fine. But you might separate them if:

  • You want a GUI editor whenever possible (VISUAL), and a TUI fallback (EDITOR) for remote or headless environments.
  • You specifically want to preserve a “line editor” for the rare scenario where a full-screen editor might fail. (Very uncommon these days, but still possible on exceptionally minimal or embedded systems.)

Can you use a GUI editor instead?

You can use a GUI editor (such as VSCode or Kate) if you’re running in a graphical environment (such as macOS or a desktop environment on Linux) as long as you can open the graphical editor from your terminal (eg. running code to open VSCode). When you’re then using a program that needs to open an editor, it should open your GUI editor in a separate window. If you go down this avenue, you should set VISUAL to the graphical editor and leave EDITOR as a TUI (or line editor) as a fallback.

In most cases, that works perfectly. However if you’re on a headless server or SSH into a remote machine with limited terminal capabilities, a lightweight TUI editor (e.g., vi, nano) is reliable. A full desktop GUI editor like VSCode or Sublime simply won’t launch there unless you’ve configured remote GUI forwarding (X forwarding or similar).

Setting the variables

These are simple shell environment variables, you can set them like any other shell variable, by running the following as commands, or adding it to your shell config or startup scripts (such as .zshrc or .bashrc)

export VISUAL="nvim"
export EDITOR="vim"

If you added the above to your shell config or startup scripts, you’ll need to restart your terminal source the script you added the lines to, for example:

source ~/.zshrc

Key Takeaways

  1. VISUAL traditionally implies a modern TUI editor that uses cursor movement and on-screen updates, while EDITOR can be a more basic fallback.
  2. You can set VISUAL to a GUI editor—but only do this if you’re sure you have the graphical environment to support it.
  3. Tools typically check VISUAL first, then EDITOR. If neither is set, they may default to an editor like vi or nano.

By understanding the historical underpinnings and modern usage, you can configure these variables to optimise your editing experience — no matter whether you’re on a local desktop or an SSH session into a headless server.