How and why I use (neo)vim

Preface: if you’re reading this and you use Sublime Text or VSCode or anything else, and this gives you the feeling that you should or must switch to vim, or that I consider it a lower class of editor and think that the mere existence of vim makes other tools ‘newbie’ tools and you immediately start installing vim and spending the rest of your day learning the modes: please don’t. If the editor you’ve been using is working for you, it’s working. Somehow text editors became status symbols in technology, the kind of topic that some jerk in the office goes ‘harumph’ when he (it’s a he) discovers that the new hire uses Coda.

Also when I’m talking about neovim, I’m also talking about vim. I switched from one to the other two years ago and, well - I enjoy neovim and appreciate the project’s goals, and I also like the vim project. For me as a user, the differences between the two are relatively minor, and the battle between the two is mostly irrelevant.

With that out of the way: I use neovim more than any other application. I switched to vim in 2011 and have used it full-time since then with few exceptions - I used IntelliJ when I had to, when I was working on an Android SDK, but switched back as soon as I was done.

Why vim

I initially switched because I had a repetitive strain injury from pulling long hours coding and complementing it with lots of playing guitar. I suspected that vim’s modal editing and complete lack of mouse-based interactions would help. I switched and the RSI got better.

I don’t mean that switching to vim fixed my RSI. I don’t have a copy of myself to serve as an experimental control and the human body is a mysterious thing. I do know that mouses and trackpads hurt my hands, because whenever I need to use a mouse constantly - like in the period I was using IntelliJ - the RSI flares up.

I also switched to vim after using a lot of other editors. I used jEdit for years, and then gedit during my Linux phase, and TextMate when I initially switched to a Mac.

I saw TextMate go out of style and other contenders enter, and that solidified my decision to stay with vim. The lifecycle of a flashy new text editor is shorter than my intended career track, and I want to invest in tools that will stick around. That very much applies to projects like Atom: I think Atom’s great, and am happy that GitHub supports it so vigorously, but I think it’s right to regard the Microsoft-GitHub acquisition with some degree of doubt. The current CEO of GitHub, promised that Atom would be maintained indefinitely, but CEO roles tend to cycle, and so do corporate priorities. And the open-sourciness of the project doesn’t mean it continues forever: projects end when nobody’s working on them. It happens all the time.

Modal editing, huh?

There are plenty of reasons to rally for vim, but the one that is so ‘sticky’ for me, the one that makes it near-unthinkable to switch away, is modal editing.

Take “quitting vim” as an example. The fact that ⌘Q doesn’t exit vim, like it does for nearly every other process, is the reason why millions of people have to Google it, and the source material for innumerable bad jokes. To dissect how you quit vim:

1. You have to be in normal mode
2. You type : to enter command mode
3. You type q to tell vim to quit
4. You hit return

What’s normal mode? What’s :q? Why do some people type :wq instead?

Keyboard shortcuts

But first: what’s normal? Normal would be ⌘Q. Command-Q. So, command is a modifier key and it doesn’t do anything on its own. Combining modifier keys with letter keys or other keys on the keyboard is how keyboard shortcuts come to be.

Take Sublime Text as an example: common operations are mostly keyboard shortcuts with 2 keys involved, but some keyboard shortcuts have as many as 4 keys you must press simultaneously: distraction-free mode is ⌃ + ⇧ + ⌘ + F.

Vim is not free of keyboard shortcuts, but it has far fewer than other applications because it is designed around modal editing. What it does have instead are:

• normal mode, in which ‘home row’ buttons like asdfghjkl; serve vital navigational purposes
• command mode, in which controlling the editor in more complex ways, like saving files, executing tests, or searching for text, can all be done with easily memorable

So most interfaces rely on a sort of chording, whereas vim is more about, well, melodies - individual keys hit in succession. This clicked with me from the start - commands could be composed in a natural way: that if I want to edit the text in a Markdown link, I can hit ci[ for ‘change inside of []’ and it’ll just work. One part of the brain remembers the change command, then another the inside command, and then surrounding character.

Vimcasts were key to learning the ins and outs of some of vim’s advanced functionality - and they still are, because I’m not even using 90% of vim in everyday usage.

The setup

My neovim setup is online - and slowly gets updates as I refine it. The key parts are:

1. Vim has really benefited from people like Tim Pope writing extremely high-quality plugins. vim-fugitive, for example, which handles Git interactions, is just world-class.
2. I started with a vim setup that was trying to imitate another editor - using NERDTree and airline to add fancy status & file browsing UIs. But removing those made everything better. Navigating only using path autocompletion and a fuzzy finder works so much better than navigating a tree.
3. The biggest disappointment has always been autocompletion. Microsoft promises to fix it with Language Server and related initiatives, but I’ve never been able to achieve a robust solution that works with a variety of JavaScript projects.

An alternative history

I think vim seems especially weird because it’s another direction that software could have taken. It’s always interesting to think of what if Xanadu had succeeded instead of the internet, or if the CLOS school of design had won out over the MIT/Stanford schools.

Text editors are an extreme example, because I think it’s entirely appropriate to view the initial battle as emacs vs everything else, and emacs won. When I look at Atom, VSCode, Sublime Text - the basic editing paradigm is all, essentially, emacs.

Vim is one of the few examples of a non-emacs-lineage editor that’s still commonplace. A rarer example is acme, which promotes mouse chording and has some really fascinating UI paradigms that are unlike anything else.

It’s a good time to think about this stuff because arguably the era of the keyboard & mouse - those basic ingredients of all UIs leading up to this point - is ending.