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 ones for 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 of
standard 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 use
the 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 working
with 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 Sweave
files.
I couldn't develop a quick keyboard shortcut to send the R code in
\Sexpr{}to the 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 world of complexity or hoping that one day someone else would write a plugin to meet my 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 a more integrated environment (e.g., outlining, task lists, etc.). When I was first learning LaTeX, R, the command-line, and so on, it was useful to 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 decent support 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 health hazard.
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 am paying a present cost for future time savings. Future time savings come both from the fact that the software is still supported and 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 developer community. 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 to another tool any time soon (but I guess we'll have to see).
The Pragmatic Programmer says 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 text editing in Vim. However, as with a lot of things, I feel the more important point is that I move my workflow to either Emacs or Vim.
The system for saving settings in Vim gives me more confidence that I can roll over my customisations easily to other machines. Eclipse always felt a bit mysterious regarding how and where customisations would be stored.
Vim appears to lack "deal-breakers". By deal-breakers I refer to something about a piece of software that is so frustrating that you just can't use it. While most software can be frustrating at times, it should be simple enough to customise 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 like there is a wall.
Building on the previous point customisation is a natural extension of the software. Vim is similar to R in this respect. While a lot of programs have a more advanced scripting language to add customisations, they don't all facilitate the gradual transition towards greater use of this scripting language.
Conclusion
Expect to see several upcoming posts on Vim as I begin to incorporate Vim into my workflow using R, LaTeX, and other tools.
