This post describes the reasons for my transition to Vim.

Brief Background

Over the years I’ve used a lot of different text editors on Windows.In general, I’ve used whatever text editor came with a program.When I started using R, I moved from Rgui through Tinn-R, JGR, and others,finally settling in to really enjoy the StatET plugin in Eclipse.When I started using LaTeX, I tried TexnicCenter, WinEdt, and Texlipse.Each program had the standard Windows shortcut keys and often a few extra onesfor tasks such as deleting lines and toggling comments.However, these novel shortcut keys varied between programs.

I’ve acquired some fairly good skills in using Windows’ admittedly limited set ofstandard text editing features.For example, I was comfortable pressing Ctrl+Shift+Right to select a word.I even developed and learnt a custom set of key bindings that allowed me to usethe navigation and cursor keys from the home key position(see my earlier post).

Nonetheless, this wasn’t enough.I wanted something more powerful, more consistent, more “awesome”.

Reasons for Adopting Vim

Frustration with Previous Tools

• I was hitting a wall in Eclipse.The StatET plugin for Eclipse has some excellent features which make workingwith R really nice (see my earlier blog post However, there were a few tasks that I could not easily automate.For example, I couldn’t get decent code folding or an outline view for Sweavefiles.I couldn’t develop a quick keyboard shortcut to send the R code in \Sexpr{} tothe R console.There was no key to switch consoles.I could go on.I could see no easy way to introduce the desired customisation.No doubt the customisations were possible, but it meant diving into a whole worldof complexity or hoping that one day someone else would write a plugin to meetmy particular needs.I could describe a similar experience with WinEdt.

Readiness for Vim

• I’d already adopted a plain-text–command-line workflow.LaTeX for documents; R for data analysis; Beamer for presentations;Make for building programs;Markdown for writing blog posts.This meant that I could do most of my daily tasks in a text editor. There was also the possibility that with Vim I could bring in other tasks into amore integrated environment (e.g., outlining, task lists, etc.).When I was first learning LaTeX, R, the command-line, and so on, it was usefulto have software that held my hand a little bit.After getting comfortable with such things, Vim is just one additional step.

• The main markup and programming languages that I use already had decentsupport in Vim (e.g., R, LaTeX, etc.).

Vim Matched My Orientation

• I like the philosophy of Vim.I touch type. I learn shortcut keys.I use AutoHotKey.I despise unnecessary movement of the hands to the cursor keys or the mouse.Vim is built for efficiency.Vim is built for using the keyboard.I’m happy to invest a little effort to get this efficiency.

• I watched Derek Wyatt‘s awesome, funny, and informative videos on Vim. http://www.derekwyatt.org/vim/vim-tutorial-videos/vim-novice-tutorial-videos/I related to what Derek was saying. I related to the “Notepad-wall”. I liked an editor that saw the mouse as an “evil” “rat-tailed beast”.I liked an editor that saw moving the hands from the home key position as a healthhazard.

Great Features of Vim

• Vim was invented in 1991 and Vi goes back much further(see Wikipedia)).It’s still very popular.Whenever I learn shortcut keys and introduce software customisations, I ampaying a present cost for future time savings.Future time savings come both from the fact that the software is still supportedand that I don’t drop the software because I find something better.Vim has been around for a long time, is open source, and has an active developercommunity. Thus, it feels like it will be around for a long time to come.Also, given that many coding gurus use Vim, I’m hoping I wont be switching toanother tool any time soon (but I guess we’ll have to see).

• The Pragmatic Programmersays that you should learn at least one powerful text editor really well.The main two options seem to be Vim and Emacs.At this point I’ve been lured by the elegance of the mode-based approach to textediting in Vim.However, as with a lot of things, I feel the more important point is that I movemy workflow to either Emacs or Vim.

• The system for saving settings in Vim gives me more confidence that I can rollover my customisations easily to other machines.Eclipse always felt a bit mysterious regarding how and where customisationswould be stored.

• Vim appears to lack “deal-breakers”. By deal-breakers I refer to something about a piece of software that is sofrustrating that you just can’t use it.While most software can be frustrating at times, it should be simple enough tocustomise the software to overcome the problem.With Vim customisation is a natural extension of the editor.With Eclipse, some useful customisation is possible, but there also feels likethere is a wall.

• Building on the previous point customisation is a natural extension of thesoftware. Vim is similar to R in this respect.While a lot of programs have a more advanced scripting language to addcustomisations, they don’t all facilitate the gradual transition towards greateruse of this scripting language.

Conclusion

Expect to see several upcoming posts on Vim as I begin to incorporate Vim into myworkflow using R, LaTeX, and other tools.

• Other Posts on Vim