bling.github.io

This blog has relocated to bling.github.io.

Sunday, February 10, 2013

Love Affair with Vim

It wasn't too long ago when I was a full-time C# developer and my environment was Visual Studio eight hours a day.  Then, I became a web developer over night cold turkey writing Javascript and CSS.  It's one of the benefits of working for a consulting company.

You might think what does that have to do with the title of this post?  Well, originally my plan was to write a blog post contrasting on the differences between Javascript and C#, as well as the development environments and deployment platforms.  But really, what I really wanted to write about was Vim.

Moving from Visual Studio to Vim was a progression through different editors and environments.  The first thing I used to write Javascript was Webstorm.  Over time I realized that you didn't really need an IDE to write Javascript/CSS.  Then, I used Sublime Text for a little bit.  But ultimately, I settled on Vim, and stayed there.

My stubbornness turned out to be beneficial when I was learning Vim because the first month was absolutely painful.  I remapped all of my arrows keys to do nothing to force myself to use hjkl.  Eventually I got the hang of it, and now I definitely have the muscle memory that makes me much more productive when editing (and reading) text.

By default Vim is just a text editor.  But I work on a project, so like most lazy people I searched for prepackaged plugins and came across two popular distributions: spf13 and janus.  When I installed them, it was like someone took over Vim and made it change into a completely different beast.  I didn't know how to use it anymore.

I took a step back.  I forgot where I got this advice, but I think anyone using Vim needs to do this: start your own vimrc from scratch.

I took a look at all the settings that spf13 and janus changed.  I copied them to my vimrc one by one, and also :helping each setting so that I knew exactly what it changed.  I must say, Vim's documentation is some of the best and most comprehensive of any tool I've worked with.  It was incredibly helpful in my progression.

Then, I did the same thing for plugins.  And the nice thing was that most plugins followed the Vim pattern of having good documentation.  After installing fooplugin, I just :help fooplugin and I got all the information I needed to know about the plugin.

I became obsessed with optimizing my vimrc, and trying out different plugins on a daily basis.  And because I was very adamant with trying one plugin at a time, I got to know them very well.  I knew about how to turn certain settings on and off, how to configure their bindings, and more importantly, how it interacted with all of the other plugins I have already installed.  Over time my vimrc became a full blown distribution in its own right, highly customized to my personal work habits.

However, even though I recommend that anyone interested in taking their Vim skills to the next level should do this discovery that I have done, there are certainly classes of plugins that I deem to be must-have for any Vim user and I wanted to highlight them here.

Plugin Management

First things first you will need one plugin to rule them all!  Pathogen changed the way people install plugins by utilizing git submodules.  This has the pros and cons of git submodules, i.e. they track a specific version of the external git repository, so if plugin authors decide to rewrite everything new users trying out your distribution will not be in for a nasty surprise.

However, this rarely happens and usually you just want the latest version.  Vundle takes the management one step further and will automatically grab source code from Github for you (as well as automatically updating everything to the latest version).

The last one and least known is neobundle, which enhances Vundle even further and allows you to specify installation steps like compiling something.

Fuzzy File Searching

This was the major game changer for me and changed the way I worked.  Naturally, proper Vim technique forces your hands to be on the home row, which makes reaching for the mouse (or even the arrow keys) to be inefficient.  Therefore, the fastest way to open a file is usually to type its name.

CommandT (written in Ruby) is noticeably much faster than CtrlP (pure VimScript), but CtrlP has a lot more features.  There's also FuzzyFinder, which I have not tried.

Autocomplete and Snippets

There are various contenders here.  Generally, you'll find that people fall into two camps.


Snipmate is an older implementation of snippets which is getting replaced with UltiSnips.  Supertab gives you an easy way to trigger omnicompletion with (you guessed it) tab, and AutoComplPop is for automatically showing the popup as you type.

Neocomplcache is a very powerful completion plugin.  It runs a little slower than SuperTab because it does a lot more, but I find the performance acceptable so that's what I'm using.  And I choose neosnippet over the others simply because it's by the same author and thus has better integration (e.g. available snippets will appear in the list).

And of course, a good collection of snippets like honza's collection.

And that's it!

What?!  No file browser?  No buffer manager?  Yes, I have all of those installed as well.  In fact, I have over 50 plugins installed in total.  But in my opinion, they are not killer features.  I can live without them.  But if I didn't have fuzzy searching or completion/snippets, I would feel a little too naked.

Out of the box Vim has some interesting defaults, mainly for backwards compatibility with Vi, but I think it's safe to say that anyone who uses Vim seriously will have a custom vimrc.  If you're just starting out and don't know what to change, sensible is a good set of defaults.

Vim has changed my work habits dramatically.  I think and dream Vim.  I install Vim plugins in my browsers.  And every day, she still teaches me new tricks.  It's quite exhilarating!

If you've read until this point you might be interested in the full set of plugins that I'm using.  If so, head over to my project page!

3 comments:

perlpetual said...

Hi,

Recently converted to vim. I am an admin guy, who has to filter through a lot of log files/command line outputs, write an occasional perl script etc etc.

Till a few days ago, I would use notepad++ for text mangling,another editor for perl scripts and another editor for another scripting language. I staunchly believed that notepad++ was the best text editor.

Till I got around vim. Whoa, I am blown. Notepad++ is still a great text editor, no doubts about it, but somehow I am getting hooked more and more to vim.

Had to change the color and the font (gvim on windows 7). But after that, and learning a couple of vim jiffy stuff, nothing like vim.

Was browsing to check on a few vim articles and stumbled across yours. Nice piece on vim. :)

Anonymous said...

Yep! I am indeed checking out your dotvim project. Thanks for all the hardwork on that. It was up and running easy and if I do'nt have any issues then I think I will build something based off of your work.

I too have had a past where VS was my IDE, but before too long I became absolutely intollerate of anything less then a terminal, VIM keybindings everywhere, and VIM with just a handful of plugins.

Screen and iPython have been pretty integral in my workflow too. On Windows you ask? Yes. I've tried everything from changing the Windows subsystem (a disappointment, no reason that should not have been perfect), Cygwin, GNU Utilities for windows, custom terminals, embedding gVim into VS... for years I tweaked my Windows environment to be more like the other environments I would jump into/out of throughout the workday. I do like the GNU Core Utilities for Windows, but other than that none of those configurations were satisfying.

Then, when I left my big corporate job; stopped using Perforce and started using Git- I found it. The Git installer for windows contains the perfect replication of a bash shell on *nix environments. It respects .inputrc and it can be configured to navigate similarly or be jailed off away from the windows-environment.

I grab the GNU tools for windows too and then I have all the awk, sed, grep, head, tail, bash, and most importantly to me the readline goodness that I need in my shell of a life.

If you've never done it before, VS project can be built from the command line. There is always a *.cmd file in the ProgramFiles menu that will get you started if you've never done it before. The name of the script changes with VS versions. The SDKs and Debugging toolkits have similar *.cmd scripts.

CDB / KDB command line debuggers. iPython and all its awesomeness. SysInternals Suite Toolkit and then the standard windows command-line tools (like reg) and there is no reason to use your mouse anymore; which is my goal. Hands on keyboard - always.

What about email? Tabing through windows brings up backgrond applications and then.... BOOM Gmail has been supporting VIM - like keybindings for several years. Outlook? Actually, I think they added them recently too, but I would rather let Google read my email than have M$ bloated, monolithic, self-important, productivity-killing applications consuming sickeningly large fractions of my system's resources while I'm trying to do actual work.


Anyway... checkout the version of BASH that comes along with Git for Windows.

Anonymous said...

One last thing....

All I do is VIM, VIM, VIM, no matter what!
My Inputrc key-bindings set!
... touching on the keys I get the feeling that my screen sessions are still up....

and they'll stay there..
and they'll stay there..
and they'll stay there..

Up. Down. Up. Down. Up. Down.
'CAUSE All I do is VIM, VIM, VIM!
Even Emacs Vims. Win - Vim.
Recycle Emacs in the bin. Vim, Vim, Vim!
Put Emacs in the bin cause trash does stay there.