Vi is a keyboard-driven editor where the standard mode is to give commands, and things such as editing text are the results of those commands. The "insert" command puts the editor in a mode that resembles the normal input mode of a typical text editor.

I use vi on a regular basis, but I still only know five or six commands. So I decided to give vi's "improved sibling" called Vim a deeper look and investigate it for my code editing needs.

Four reasons why I tried Vim

A number of people whom I respect put a lot of stock into Vim as a code editor.

I find myself working on *Nix systems from time to time, where my normal apps are not available. Why force myself to keep going back to my desktop to make and change and then re-upload it when I could make the change directly on the system?

I've been exploring outside of the Microsoft ecosystem a lot lately. For instance, I recently got around to shifting all of my personal development from TFS to Mercurial, shutting down my TFS VM, and giving that RAM to another, more useful VM (I see a Kiln + FogBugz test in my future).

Installing Vim

I downloaded and installed the gVim package from the Vim website. The install package was small, and it went quick. It also offered to install a Visual Studio plugin, but I have not been able to see it in Visual Studio 2008 or 2010 since the installation, and the documentation has not been very clear on that topic. (Vim is free and open source, though the authors encourage you to make a donation to charity, which I chose to do.)

Learning about Vim

Vim is a very feature rich application; it's a text editor with enough meat to justify some books about it. In many ways, Vim reminds me of WordPerfect 5.1: It's an extremely powerful, keyboard driven editor that requires a fair amount of time and energy to leverage, but the effort is well worth it.

After learning a lot more about Vim by going through the tutorial (which walks you through the most common commands), I can see why folks who use the code editor on a regular basis swear by it. Vim is extremely powerful, if you take the time to learn it. Little details, such as knowing that you can apply commands to individual words or lines or multiples of such with a simple twist, go a long way to speeding things up.

Using Vim is different enough from other editing systems that you need to approach it with a different mindset. Until you really internalize the Vim way of doing things, you won't be as effective as possible. Vim appeals to people who figure out how to "min/max" every aspect of their day, but if that's not your style, you won't get much out of the code editor.

Reflecting on Vim's use for my work

I feel that Vim is of limited value for my particular workload. Vim would be an awesome tool if I were to return to the Perl days of my youth or shift my development work to Ruby (Figure A is a screenshot of gVim editing Ruby code).
Figure A

Editing a simple Ruby program in gVim

Hand editing HTML and CSS would also go really well in Vim, especially with heavy use of its scripting system. In those languages, you generate a lot of text and don't need nearly as many libraries to get stuff done, depending upon your project.

In my Perl projects, the overwhelming majority of my work stuck to a handful of expressions. But in the C#/.NET world that makes up almost all of my work, IntelliSense is a mandatory item to explore the things you don't know (Visual Studio's awful new Help system makes it even more necessary). Losing IntelliSense is a huge hit to my productivity, simply because it's so difficult to get from Point A to Point B in the .NET world without encountering at least some namespaces you don't know intimately. Even worse, in C#/.NET, so much of the work is spent doing things that could be considered refactorings that it's best to use a tool that's really designed for the task at hand.

Conclusion

I'm definitely leaving Vim on my system, and the next time I work in Ruby, I plan on using it in lieu of Visual Studio. As you can see in the screenshot, Vim has no problem working with Ruby and giving it the syntax highlighting treatment.

At the very least, this experiment reminded me of something that continues to frustrate me with C#/.NET: I feel like I write very little code and spend most of my development time trying to push buttons on existing libraries or get the tools to generate 30 lines of skeleton code to place my two lines of real code inside.