I originally wrote this as a response to “Sublime Text 2 vs Vim” on reddit, but it was too long to post. I blogged instead.
TL;DR I cannot in good faith recommend Vim to a new developer, even though I use it.
Vim: The Editor You Need To Read (At Least) Two Books On To Use Well
Vim is not a more efficient editor for regular text editing. It’s not going to make you type faster. For the first 1-2 years of your Vim usage you will be much less efficient than your current editor because of the odd yet lovable key bindings. After about 2 years you will be proficient.
Everyone talks about the steep learning curve but no one talks about what happens once you finally get hjkl in your brain for movement. The answer is months of frustration, followed by finally having a usable editor, followed by knowing some cool tricks that you use in 1% of your daily workflow.
Efficiency from Keeping your Fingers on the Home Row
The argument that Vim is more efficient is dubious and untestable. Reaching
for a mouse may indeed slow you down, but developers are commonly on machines
where the trackpad is a micro-hand movement away. Most novice programmers can
click on a character on screen faster than an expert Vimmer can type
/word<cr> or any other nasty way Vimmers have to use because of
our archaic, ingrained keystrokes.
The point of a mouse is to make arbitrary on screen jumps efficient, and it’s very good at doing that. Don’t you ever think you can beat a mouse. Only in very few edge cases will it even matter.
The mouse argument is trivial. The real problem lies deeper.
Plugins and Extensibility 1: Management
The Vim plugin community has some deep and odd flaws. Consider that Vim has been around since 1991. Pathogen, the first widely used, known, and celebrated path manager making plugin management possible, was released in 2008! Before that, you were encouraged to recursively copy the plugin’s directory into your Vim folder. I’m not kidding. There’s even a special, praised shit-format in Vim for doing this, called a Vimball (VBA). Many plugins scripts still use this format. Try uninstalling a plugin that you copied into 10 folders a few months ago. Try upgrading it!
Vim is touted as being an extensible, customizable editor, and it is. It’s probably the most customizable editor ever, but we never had any proper package management until very recently. This is worrying. Vundle didn’t even come out until 2 years after pathogen. Even pathogen and vundle are limited compared to Sublime Text’s Package Control plugin.
This is all especially scary because Vim out of the box is awful. I can’t stress how bad of an editor vanilla Vim is. Plugins are essential to make Vim usable.
Plugins and Extensibility 2: Ecosystem
Vim Scripts. Barf. Think CPAN with less formatting, fewer features, and more ads.
Most Vim plugins haven’t been converted to Github projects yet. Vim Scripts acts as a featureless host, which is fine, except that it doesn’t offer any benefits. It has a nasty interface, and encourages the use of the Vim Wiki for project management (more on that later). Much of the Vim plugin community revolves around this barfy site. There is an effort being made to auto-convert Vim scripts to Github projects which may be promising, or may be a disaster.
Plugins and Extensibility 3: Vimscript
Ah, Vimscript. It’s bad. And yet we’re stuck with it. If you want to write a plugin you have to deal with Vimscript. It isn’t necessarily a bad language. The syntax is a little goofy but it’s forgivable. The main problem with Vimscript is that it’s not another language. No one knows it. Most experienced Vimmers I know don’t know any Vimscript. And how would they? The documentation on it is terrible, and made much worse by the fact that it’s near impossible to look up help on it.
You might find a Vimscript tutorial on the Vim Wiki (try searching for Vimscript to learn just how bad their search is, another reason not to use it), but I honestly think most of the authors have some personality disorder. There are no friendly, accessible, story-like tutorial to be found. It’s documented by robots and emotionless coders.
Let’s say you want to write a function. Ok. let’s look up the help for function.
:help function. Oh good, this isn’t what we want at all. Let’s type
vimscript I guess. What the fuck is this? Side note: all of Vim’s help is
equally poorly accessible. Fortunately, a few good resource sites exist
(Learn Vimscript the Hard Way).
But even Vimmers don’t want to learn Vimscript. God willing Vim will one day have a non-Vimscript language we can use. There have been discussions of making Vim adopt ECMAScript (Re: replace VimScript) but no one has had the balls to attempt it, including myself.
Plugins and Extensibility 4: Collisions
This is a big one. Vim is missing an incredible amount of core functionality for modern editing. Things like ctag integration, project management, project browsing, (yes I know about :Sex), and many other basic things, are completely absent in Vim. This is by design because Vim was never meant to edit any single language, except maybe C. This isn’t necessarily a bad thing! Vim can in theory edit any language because of its extinsibility power, although it will have a very hard time with IDE-languages like Java or Scala.
Ok, we need a project-like file browser. Let’s get NERDTree, most people know about that. But wait, NERDTree keeps leaving shitty things open when I close buffers. Most people don’t know about NERDTree tabs, but NERDTree is incomplete without it. And ugh, it looks nasty because of Vim’s monospace font restriction for the entire UI (more on that later). But I guess that’s not so bad…
Now we need to find files. Let’s use Vimgrep! Oh wait, that sucks. Ok let’s get Command-T. Oh wait that’s incredibly slow and clunky and looks jenky. Oh, there’s CtrlP this is much nicer! Except, wait it doesn’t actually do correct fuzzy searching, so now my results are inaccurate. Do I want slow and stupid or do I want fast and wrong? Or do I wan-fuck it.
Sublime Text’s Command-T “just works”, works incredibly well, looks amazing making scanning files 100% easier. Padding around your text to make it readable? What a concept!
Finding the right Vim plugins is like being in an exclusive club. It gets better around year 2 of your journey, then worse around year 3, then…
Back to collisions, there are many plugins which touch the same functionality, because default Vim offers so little. Need snippet completion? Get snipMate! But wait, UltiSnips is better! But wait, both go into hell if you have neocomplcache installed! (Side note, I couldn’t pick a worse name than ‘neocomplcache’ if I were offered 10 million in unmarked bills to accomplish it). Now you need neosnippet! But wait, if you have any other auto complete plugin it will fail! And all of these plugins are gauranteed to fuck up Vim’s default, already complex and confusing auto completion!
Your search plugin will collide with your auto complete plugin. Your syntax plugin will collide with your dictionary. What does a collision mean? It means randomly Vim will spit out 500 lines of highlighted red text at you, but just for a second, just to let you know you fucked something up. You’ll get cryptic errors with function names you’ve never seen before if your search regex is invalid, from indexed-search (which you want, because why the hell isn’t that in Vim by default). You’ll see a huge red flash of text at startup that you can’t read, copy, nor save, and it goes away after 2 seconds, and suddenly your editor is slow a dog and you have to go plugin witch hunting.
Ah, the extensibility of Vim.
Vim Is Bad By Design™ 1: Oooooollllld
Leader from backslash to comma. Backslash was chosen because
it used to be convenient to type, in like 1943 or something. Now it’s in an
awkward place on most modern keyboards. The remap overwrites comma, which is a
very useful keystroke, but it’s worth it to avoid the archaic backslash leader.
Do you know what the suggested way to work well with multiple files in Vim is? It’s the arglist. Most of my experienced Vim friends don’t use the arglist nor know what it is. It’s a clunky system for populating a special internal list of Vim with multiple files. It can actually be quite handy at times (with a few plugins), but you may only use it three times in your whole Vim career. It’s a weird, archaic, specialized knowledge wart of Vim. And you’re going to need to know it, probably around year 2.5.
Vim Is Bad By Design™ 2: GUI
Vim is designed to run in a terminal. That’s why it’s explicitly linked to only monospaced font for the GUI. A terminal can’t draw a UI. I get it, we have to draw things with blocks and underscores and what have you. Ok, I’m fine with that. I’m on a server, I’m editing a file probably as a hotfix for something, I don’t need a beautiful editor to do that. I just need to edit text.
But Vim is supposed to be an editor that you don’t always have to use on a server. You can use Pico on a server as well, but no one uses Pico to do actual long term editing. Here in the future, we have these things called GUIs. They’re super nice! They look good, are usable, and give useful visual metaphors for things. And we logically and reasonably expect our editors running on GUIs to offer the same benefits.
Do you know what benefit MacVim has over terminal Vim, visually? It has styled tabs. That’s all we get, and that’s all we’ll ever get. Text cannot nor ever will have padding for readability. You cannot show more than one font size on the screen at once. If you want to zoom in your buffer text, you also zoom in your file browser. And your command line. And your status line. If you want to use a more readable, non-monospaced font to style a dialog, then you’re going to be very sad.
Vim is hideous by design. It looks like a child just learning how to draw a cow with a bash script made it. We will never have a minimap (beautiful feature). We will never have multiple cursors. We will never have a pretty fuzzy file finder that pops up in a reasonable location. We can’t place dialogs in arbitrary places for usability. We will never have a customizable dialog anything. The closest you can get is vim-powerline, and that’s still just drawing with blocks. Honestly, Vim’s UI gets old. Sure, I’m mainly editing text in here, but I’m here for most of my work day. I want it to look and feel good. Vim has lots of neat bells and whistles, but many of them are just hacks and tricks to get around the fact that we don’t have a real GUI.
Vim is Oddly Bad at Indenting
Don’t believe me? Paste this into an empty buffer:
<div> <p> <span>foo</span> </p> </div>
:set ft=html and then
gg=G. Let me know what you get. In all
seriousness, never, ever tell me what you get.
For some strange reason Vim is bad at most indenting. Forget about having
shiftwidth you’ll turn to plugins, you’ll find
quite work and a forked version but no that has problems too, and someone else
has something named the same thing but it’s different? I don’t really know why
it’s such a mess and it’s my fault for not investigating it myself, but why the
hell do I have to configure my editor to indent common languages? You should
know already, Vim.
The Life Long Vim Journey to get a Reasonably Usable Editor
*To code in Vim, you have to keep Vim in your head just as much as the code that you’re editing. You have to constantly think about what you’re doing.
Maybe this is a good thing. Maybe it encourages efficiency and refinement of
practices. But you know what? I don’t want to deal with that. I don’t want
to have to remember what
@@ does or what
:v/\v does or a fractal web of
things to accomplish basic tasks. Despite this, I do. I spend at least an hour a
week working on Vim-fu. But I don’t want to. I want to edit text. I don’t want
to read yet another tutorial that counteracts something else I had finally got
down so that I can rename a function correctly. I just want to make things.
Perhaps it’s a necessary evil. Perhaps at year 10 it will all have been worth it
because I won’t have to think to do things. I don’t know.
After four years of Vim use, 700 hand written lines in my .vimrc, and 45 plugins, I cannot in good faith recommend that someone start the Vim journey.
I want my coworker to edit text and get up to speed quickly. Is telling them to use Vim the answer? It will just slow them down for months. This is not pragmatic to the technology industry. Maybe it will pay off in the long run. Maybe I just don’t want to deal with their Vim journey.
Look kid, I love you and all, but just use Sublime Text. Despite the fact that I moved writing this post into Vim because I couldn’t stand to do it in a textarea, even though I’m mainly just typing text. I missed my Vim movements too much. Despite the fact that I will probably never stop using Vim.
You’re going to have to know Vim. You’re going to be useless in the
technology world if you can’t edit a file remotely, which will you will be in a
terminal for, and which you will be using Vim for. You won’t be able to live
set -o vi on the command line to get Vi bindings in bash, and I will
judge you forever until you actually use it…
But Sublime has things Vim can never have. It’s the new hotness and has a more active community than Vim does. You’re lucky to see a Vim plugin that has been updated in the last year (not to diminish the incredible work of superstars like Tim Pope, who I would kill for, but they are few and far between).
Vim is a lifelong journey. Even now I want to convert this text, which I wrote in Vim at 80 columns wide, to non-fixed width text, and I’m going to go search for how to do it. I’m probably going to learn something in the process. At year 4 of Vimming.
If you find Sublime isn’t for you, or feel like you’re missing power, then you
can try Vim. But you can get by with editing files on servers with minimal Vim
knowledge. You can use
set -o vi without reading a book.
My opinion may change in later years,
but for now, if you need to make a choice, just use Sublime Text.
:set tw=10000 | norm gqie, with textobj-entire, duh)