The Efficiency of Vim
Published 2025 February 24I learned to touch type in fifth grade. We would shuffle into the computer lab and open up Mavis Beacon Teaches Typing1. I peaked at about 80 wpm. Today, I type somewhere between 60-70 wpm. If I am writing code then that drops to 40-50 wpm. It bothers me that I can't crack 100 wpm but what I have come to realize is that text editing is less about typing speed and more about typing efficiency.
Touch typing was the only efficiency tool I used at the computer until I learned to program. Programmers tend to not like to reapeat tedious tasks2 and there is an entire field of efficiency tools to use a computer. Not all of them bear equal fruit. You can endlessly configure your tools and never get anything done.
VS Code was the first IDE I used. I tried to learn some of the shortcuts for text editing but still used a mouse-heavy workflow. As the programs I worked on became larger, the overhead of using a mouse began to disrupt my flow. Luckily, I was introduced to Vim3 via "The Missing Semester of Your CS Education" by MIT4. From their page on Vim we read:
When programming, you spend most of your time reading/editing, not writing. For this reason, Vim is a modal editor: it has different modes for inserting text vs manipulating text. Vim is programmable (with Vimscript and also other languages like Python), and Vim’s interface itself is a programming language: keystrokes (with mnemonic names) are commands, and these commands are composable. Vim avoids the use of the mouse, because it’s too slow; Vim even avoids using the arrow keys because it requires too much movement.
The end result is an editor that can match the speed at which you think.
I was intrigued by the aspect of ditching my mouse, while editing, so I set out to learn Vim.
Pain points #
I soon discovered that Vim has a steep learning curve. If feels completely foreign to someone used to a mouse-based workflow. However, early users of computers relied heavily on the keyboard instead of visual feedback. Practival Vim5, shares a bit of this history:
ed was the original Unix text editor. It was written at a time when video displays were uncommon. Source code was usually printed onto a roll of paper and edited on a teletype terminal. Commands entered at the terminal would be sent to a mainframe computer for processing, and the output from each command would be printed. In those days, the connection between a terminal and a mainframe was slow, so much so that a quick typist could outpace the network, entering commands faster than they could be sent for processing. In this context, it was vital that ed provide a terse syntax. Consider how p prints the current line, while %p prints the entire file.
ed went through several generations of improvements, including em (dubbed the “editor for mortals”), en, and eventually ex. By this time, video displays were more common. ex added a feature that turned the terminal screen into an interactive window that showed the contents of a file. Now it was possible to see changes as they were made in real time. The screen-editing mode was activated by entering the
:visual command, or just:vifor short. And that is where the namevicomes from.
Most tutorials to Vim, point you to vimtutor which is where I started. Each day, I would go through a single chapter of vimtutor and try to use it. Eventually, I installed the IdeaVim extension6 from JetBrains and never looked back. It was a rough transition but I think everyone has to eventually jump into the deep end and force themselves to swim.
After about a month of daily usage, I could not imagine a world where I did not use Vim. I used to use arrow keys to move around my code, but depending on your keyboard, they are inconveniently placed. Vim makes it so you never have to move your hands from the keyboard. You simply switch between modes. The action performed by each keypress depends on the current mode of the editor. This is why Vim is considered a modal editor.
Many programmers' introduction to Vim is the first time they use git commit. Git opens your default editor, which is usually Vim on Linux, for writing the commit message. This is why one of the most commonly searched things about Vim is "How do I exit Vim?"7.
Vim Everywhere #
I am not alone in my affection for Vim. There is a Github repo titled "Vim Keybindings Everywhere - The Ultimate List"8. It includes the following introduction:
Once your fingers have learned to speak Vim, they don't want to speak anything else! It's simply a very effective way of navigating, creating and editing text. Thus, it's natural that one would like to get Vim-like keybindings in as many programs we use as possible.
One place I found Vim keybindings the most useful was on the command line. Bash, which uses GNU readline for input allows you to turn on Vim-like keybindings using set -o vi. It makes the command line becomes more tolerable to use and edit.
Other options #
Vim is not the only editor out there. One notable example is Helix9. Vim uses the action → object or action → selection structure for performing operations whereas Helix uses the object → action, or selection → action structure10. I picked both of them up about the same time and use Helix fairly heavily as my main editor in the terminal. I have tried to use Neovim11 but configuring it to match what I get in Helix is not worth the effort. I think using a scripting language, Lua in this case, for configuration is bad for adoption. Configuration should be declarative not imperative.
I also discovered Parinfer12, an editor for writing Lisp. As its name suggests, this editor keeps indentations and parentheses in sync. I don't write Lisp but I am assuming it is a common task when doing so. This type of editor is known as a syntax-directed editor or structure editor13. Wikipedia states the following:
A syntax-directed editor may treat grammar rules as generative (e.g., offering the user templates that correspond to one or more steps in a formal derivation of program text) or proscriptive (e.g., preventing a phrase of a given part of speech from being moved to a context where another part of speech is required) or analytic (e.g., parsing textual edits to create a structured representation). Structure editing features in source code editors make it harder to write programs with invalid syntax.
Language-sensitive editors may impose syntactic correctness as an absolute requirement (e.g., as did Mentor), or may tolerate syntax errors after issuing a warning (e.g., as did the Cornell Program Synthesizer). Strict structured editors often make it difficult to perform edits that are easy to perform with plain text editors, which is one of the factors contributing to the lack of adoption of structured editing in some domains, such as source code editing.
A lot of text editors do offer a hybrid of structural or syntax aware editing. I think as language server protocols progress in complexity, we will continue to see new and unique ways of thinking about text editing. We have only been using text editing programs since the last half of the previous century. There are more text editors to choose from than there have ever been since their inception!
Vim has fundamentally changed how I think about programming. It eliminates the overhead of editing text. I feel less fatigued and can maintain longer sessions of work because I use it. It provides me with an undeniable efficiency. For new programmers, I might not suggest it from the get go because learning programming is already filled with a bunch of rabbit holes. As I mentioned before the learning curve is steep, but you do not have to learn in all at once. Ultimately, I think the most important part of Vim is the ideas it contributed to the text editing world.