tl;dr: VIM is becoming a fad and the people that advocate it are VIMposers that just copy someone else’s dot-files and talk about productivity when, in fact, VIM doesn’t magically make you more productive nor does it make you faster. Instead, if you genuinely want to use VIM, you should check out Coming Home To Vim and learn VIM by learning Vimscript the hard way. If VIM doesn’t suit you, you can pretty much make yourself way more productive in your current Editor by doing what VIM-masters do, setup custom shortcuts and customize your editor to behave how you want it to. The End.
Just like a lot of old-school things that make us reminiscent of the greybeards of technology, VIM is making a comeback. With at least one story a day on HN about VIM, and at least one big popular developer making “the switch”, it’s up there with other trendy things like Rust, and Go, Haskell, and until recently Node (thanks TJ!). So among these articles about Functional Programming and composition over inheritance, there is a steadily growing userbase of people that blindly switch to VIM (and TMUX while they’re at it).
So without further ado, let me tell you why I joined the bandwagon, why others did, and most people are doing it wrong.
To cut straight to the conclusion for those with ADD in the audience:
No, VIM did not make me into an amazing developer. No, I do not just “press a few keys” and make shit happen. And lastly, no, I would not say VIM is the key to being the best coder out there, nor is it the best editor.
For those still here to listen, I’ll tell you my story.
I first started out coding in Notepad like any other proper web developer and soon upgraded to Dreamweaver, the tool of the gods for people like me. It had code-completion, it had livereload/live preview, it had superb code highlighting for files from php to css. On top of that, it had code collapse, and a sort of “prettify” function which indented your code correctly. Oh, and simple errors/bugs would show up right away. And FTP, filetree. You know what, it was an IDE and that’s what you’d expect from it, to have everything you’d need.
Jumping from nothing to that was a dream. Productivity up by a million percent. Unimaginable to go back. One day though, I started working at a C# shop and saw another big jump and it was Visual Studio. It upgraded my view of code editors to the point where, again, I could not go back. Multiple code panes, refactoring, post-processing, cross-file code-completion, package management!, oh my! What a wonderful tool. My productivity went up, by about a hundred. Most of those tools, truth be told, were sugar on top of everything else.
There was still a file tree, still neat highlighting, and other features.
When I switched jobs and had to make a hardline decision as a Lead Developer, I could not justify going the C#/Visual Studio way (I wasn’t experienced enough and PHP was my strong suit) so I tried to pick up the next best thing for PHP coding, WebStorm. What looked like a great analogue to VS but for PHP turned out to be a disaster for me. I could not stand working with it. Too many panes, too much stuff, and on top of that, everyone wrote about Sublime Text 2. So I got that editor and used WebStorm for FTP and debugging.
ST2 is truly a wonderful unobtrusive tool. With its quick file opening, great extensions, and sleek minimalist interface, I could not go back to these “heavy IDEs”. ST2 worked well for me for a couple of years until I ran into a developer who told me how VIM has been the best thing for him.
Eager to find an ST2 replacement and pick up VIM, I tried it and it worked. So why did I go with VIM? It wasn’t productivity, it was comfort. I felt more comfortable working shell-only, and switching from OS X to Ubuntu without a hitch and without other tools to install. I did not become a better coder but I do enjoy coding more. I did not become a master at shortcuts (can’t do the whole
:djsdfakjs to suddenly refactor my code), but I do enjoy working mouse-less.
And as much as my co-workers and friends tried to work with VIM it didn’t work for them, and that’s fine, because it doesn’t work for everyone. It won’t, for instance, work for most people in my opinion.
VIM and You (and the Others)
When someone tells me they’ve “tried VIM but could not get into it”, I ask them three questions:
- Did you customize VIM first?
- Were you an overnight VIM fundamentalist? (A…VIMposer?)
- What were you expecting?
The first question is aimed at those who run
sudo apt-get install vim or
brew install vim or whatever and expect to jump right in, shortcuts cheatlist ready, and stand a chance. That won’t fly. I highly recommend reading Coming Home to Vim and get started there. Without at least minimal customization, VIM won’t be usable to most people needing to use VIM in a work environment.
The second question is aimed at those who already subscribe themselves to the fundamental rules of VIM without even using VIM yet:
- no arrows
- no mouse
- all shortcuts
c, and other shortcuts in lieu of the delete button
- rarely use
- (and install someone else’s dotfiles)
The “tough love” of vim turns many off, and I gotta tell you, I still use my arrow keys and although I don’t use my mouse, I don’t use shortcuts heavily either, and rarely ever at first. I still don’t get into using
c but at least I got
Going from nothing to fundamentalist extremist views will drive you nuts. Take it slow, even use a mouse if you have to.
Number 3, so what were you expecting? Were you expecting developer zen? or coding bliss? Perhaps you expected your code to be magically 1000% better or work to be 1000% easier. None of these will happen, at least not in the first few months of using VIM. Your productivity will bounce back into its regular norm and then snowball with time. The problem is, the snowball isn’t immediate, it really does take time. Months, even longer.
As a sidenote, if you want to be a better developer, get yourself a copy of Code Clean because that would be something actually useful to do.
How I set up VIM (and how it differs from the Others)
I’ve seen some great people post about their VIM setups and they all share a few commonalities:
- some hack to keep them from using arrow keys
- solarized theme
- a bunch of common remaps, most of which they don’t use or don’t know what they mean
- and rarely ever customization
By customization, I mean shortcuts that work specifically for them. It feels like most of these people just download a prepackaged dotfile and keep rolling and then they eventually quit because they don’t know how to use VIM despite advocating it. I call them VIMposers.
They create “sane defaults” and never deviate from it, thus losing out on awesome VIM stuff. That’s not what’s great about VIM. So let me tell you a few things I do that others don’t:
- customize guifont
- use a darker theme after experimenting with 10s of different themes (no solarized here!)
- custom hotkey to switch themes from my default greyish tone to a darker one at night (1 and 2)
- specifically map hjkl keys to work with columns rather than lines (works very well on wrap)
- strip whitespace function
- custom hotkeys for windows splitting (w for vertical and q for horizontal + custom mappings for window switching)
- custom buffer hotkeys (buffernext, previous, delete, and even new file and list)
- autocmd that match filetypes, I use a custom list so I can add neat stuff like
.txtto have automatic markdown syntax highlighting
- onsave extra whitespace showing
- built-in command to compile LESS
- tabularize shortcuts for
- paste toggle (when pasting text, this disables autoindenting)
- command-t extra options to ignore
vendor(might remove the last one). An option to wait longer to search after I press a key, and using OS X “watchman” instead of the ruby extension to find files. And also performance tuning for large projects.
The other thing is, I detest MacVim or GVim. Seriously. The whole advantage of VIM to me is the fact that I can use iTerm or TMUX and run inside that terminal along with other apps, and don’t have to leave. If I have to leave my terminal for file editing, I must well use Sublime Text or a heavier IDE. I don’t want that, and I could honestly care less about better colors, 256 is good enough for me.
The only thing I feel like is missing is good code completion but I’m sure I just haven’t stumbled on the right plugin for that.
And just to explain why I made all these changes, they were all driven by watching the tasks I repeat often or that are inefficient and finding shortcuts. That’s what I meant by “snowballing with vim”. You start off without the knowledge of anything, then you start to glance at the cheatsheet once in every while to find out how to perform some act of miracle and then you take it a step further, and find your own solutions.
Learn Vimscript the hardway starts out by basically teaching you how to create shortcuts to delete the current line in insert mode, uppercase the word your curser is standing on, and much more. This is actually useful stuff. And stuff that you learn and use along the way.
I, for example, implemented a hotkey for switching themes because my day-time theme was too bright at night. And sometimes my eyes needed a change so I just switch themes on the go, without touching the settings
Whitespace were a big issue for me as well. Not only did I find a good “strip whitespace” function but I also found a highlighter that automatically warned me of trailing whitespace.
The list goes on. I created a shortcut for LESS because I work with it often and did not want to bother with setting up
grunt every single time.
Lastly Command-T is the best search tool I’ve seen and can easily sort through my several thousand files worth of crap. Faster than Sublime Text I’d say. Especially once I read through the docs (omg, reading through docs, right guyz, who does that?) and found out about using watchman for faster querying and better results.
All of this adds up. I’m thinking to myself already, what issues do I have now? I’ll probably find a solution soon and a bottleneck in my productivity will be gone. But none of this would have been possible “just by switching to VIM”.
I have a pretty big list of plugins (especially compared to some other people) but I have a good reason for it and I frequently audit my plugins. If you check out my vim-setup, you’ll see that plenty of my plugins are commented out. So here we go:
- Vundle – plugin manager. Grabs the repo for a plugin, pulls it, and loads it up
- Fugitive – git wrapper for using git inside VIM. I don’t use it often but when I do, I’m glad I have it
- Vim markdown – highlighting for markdown. Has a ton of other features that I’ve yet to explore.
- Vim less – syntax highlight for less
- editorconfig vim – obviously, an editor config plugin for vim (to abide by styles set by the
- vim airline – neat statusbar that also keeps track of my buffers
- vim gitgutter – gitgutter adds my git status next to the line numbers. If I added any lines, deleted, or changed, it shows up as +, -, or ~
- Nerdtree – file tree utility, works and looks similar to ST2
- Nerdcommenter – a utility that allows me to comment out large blocks of texts and toggle comment status
- syntastic – a plugin that checks syntax for me for mistakes and problems
- vim-jade – jade syntax support for vim
- tabular – a formatting tool, allows me to align my
- command-t – a quick search/lookup/open tool for files in my project
As is the fashion,