The ways in which we interact with computers has changed dramatically over the decades. From flipping switches on the control panels of room-sized computers, to punching holes into cards, to ultimately the most common ways that we interact with computers today, in the form of keyboards, mice and touch screens. The latter two especially were developed as a way to interact with graphical user interfaces (GUI) in an intuitive way, but keyboards remain the only reasonable way to quickly enter large amounts of text, which raises many ergonomic questions about how to interact with the rest of the user interface, whether this is a command line or a GUI.
For text editors, perhaps the most divisive feature is that of modal versus non-modal interaction. This one point alone underlies most of the Great Editor War that has raged since time immemorial. Practically, this is mostly about highly opiniated people arguing about whether they like Emacs or vi (or Vim) better. Since in August of 2023 we said our final farewell to the creator of Vim – Bram Moolenaar – this might be a good point to put down the torches and pitchforks and take a sober look at why Vim really is the logical choice for fast, ergonomic coding and editing.
First, There Was Vi
Text editors weren’t originally really much of a thing when it came to home computers, with the need to edit text and configuration files the most pressing on larger UNIX systems. This was the world in which the vi editor (short for ‘visual’) saw the light in 1976, when Bill Joy created it as a visual mode for the
ex line editor that worked better on a teleprinter. Bill Joy did admit to being strongly inspired by the modal Bravo editor, which was created at Xerox PARC in 1974 for the Alto Executive operating system.
As the standard editor in BSD Unix distributions and part of the Single UNIX Specification,
vi became well-known and despite it being proprietary software, demand grew for a version that would work on home computers. This turned out to be Stevie (ST Editor for Vi Enthusiasts), originally written by Tim Thompson for the Atari ST in 1987, but later ported by Tony Andrews to UNIX, OS/2 and Amiga in 1988. It was this Amiga port that Bram Moolenaar – as an Amiga user – would pick in 1991 as the basis for what would become Vim.
Initially ‘Vim’ stood for ‘Vi IMitation’, but after the project picked up speed and gained many new features that made it much more than ‘just vi’, it became ‘Vi IMproved’, or ‘Vim’ for short. Even though Bill Joy had by then joined the Dark Side with his entry in the Church of Emacs, this did not mean that the mode-based editing approach first coined with the Bravo editor at Xerox PARC was now on the ropes. Instead Vim is still the editor you’ll usually find installed by default on Unix, BSDs, Linux distributions and others, whether in its vi-compatibility configuration or full Vim glory.
Vim is the canonical mode-based editor. Perhaps the most straightforward way to describe the difference between mode-less and mode-based text editors is in the way that modifier keys are used. If you want to perform commands with a mode-less editor, you have to use the Alt, Ctrl, Shift, Meta, or Cmd and some of the alphanumeric keys simultaneously to form the key combination that triggers the desired command. Depending on the number of these commands are configured this can mean simultaneously hitting a mere two keys all the way up to five or more in some kind of claw-like death grip. In the case of Emacs the common issue with a sore finger is referred to as an ‘Emacs pinky‘ from overextension to the Ctrl key.
With a mode-based editor, you hit the configured key (like ‘Esc’) to leave the Insert Mode and enter Command Mode where you type out the string with the command. From a repetitive strain injury (RSI) point of view, it ought to be somewhat obvious that the latter approach puts less stress on one’s hands and wrists as they can remain mostly on the home row, rather than having to contort continuously to reach for modifier keys to form uncomfortable combinations, or even shift your position for that bane of ergonomics: the mouse.
Beyond the inevitability of accessing the Shift key now and then in order to capitalize a letter here and there, or to hit Caps Lock for that bit of SQL syntax, your hands should remain on the home row when using a mode-based editor like Vim, with your weak pinky rarely having to exert a trembling reach all the way over to the Alt and Ctrl keys. When you are done typing in whatever text had to be typed in Insert Mode, you move your left hand slightly over to hit the Esc key to enter Command Mode, which is also a nice change of position that allows for stretching your hands some.
Vim As IDE
Although Vim started as a text editor, it has over the decades collected many features which are generally associated with integrated development environments (IDEs). This include syntax highlighting, code folding, integration with toolchains and a robust extension ecosystem that allows a user to turn a basic Vim installation into an IDE for whatever target language and environment they need.
In order to get started with configuring Vim as an IDE, you only have to follow one of the countless tutorials you can find all around the internet, owing to just how many people use Vim exactly for this purpose. Some mention trying out countless other IDEs and editors, only to come back to Vim. One thing that is highly attractive here is how transparent and configurable it is. You can quickly check and configure settings in the plain text configuration file, and share these settings with others, or simply back up your entire Vim configuration, which is very convenient when switching between systems.
Finding additional plugins for Vim can be a bit of a chore if you’re looking for something specific, but the official scripts database on the Vim site, as well as as sites like Vim Awesome can help with sifting through what’s available. There are also plenty of recommendations by Vim users on which plugins they figure are the best for developers and sysadmins. Although perhaps not as glitzy and user-friendly as something like Visual Studio Code, Vim will happily run on the command line, even inside a screen session via SSH on a remote server, without requiring a gigabyte of RAM and lugging a browser-sized attack surface along with it.
For the average computer user, vi and Vim, Emacs and mode-based editors are something that they will likely never come across in their daily, Windows and MacOS-based experience. To them these sound and look like tools used by hackers, as they sit in darkened rooms in front of multiple screens with text busily scrolling past in terminals. Yet when the Editor War first began to pick up speed, that was basically all that computing was like, whether in DOS, CP/M, UNIX, or the various BASIC runtimes including that of the pre-MacIntosh Macs.
In that era nobody was quite certain what the best way to create a user interface was, with even the GUIs of Windows 1 through 3.xx looking quite bizarre to today’s generations. These days we have more or less settled on a few standard ways of interacting with computers, but as the ongoing strife between the Church of Emacs and the Enlightened of Vim shows, nothing is ever fully settled, even as both sides bring their best arguments to bear.
Regardless of what the future of computing will look like, we all owe Bram Moolenaar a thanks for his role in giving us Vim, and kickstarting the community around it.