NOTE: This post is not about the editor war — so please don’t try to start one either.

First, some background. Lets just say that I lost my editor virginity to Vim. It was a brief, but violent introduction — the modal editing was too unfamiliar, the learning curve too steep. After dabbling with a few other conventional editors (such as KWrite), I settled upon Emacs (XEmacs actually, but thats another story).

For the next three years, I tweaked my .emacs file, fiddled around with settings and plugins and modes, played games and browsed the web, checked my email and newsgroups, all within the comfortable confines of Emacs. But I was getting wary of the long startup times and (at that time) the inability to use the same interface and features in console mode (such as over SSH) as in GUI mode. It was time to move on.

I rediscovered Vim around 6 years ago. I started with a clean slate. As the saying goes, Emacs is an operating system that also happens to have an editor in it. The relatively more focused feature set of Vim was refreshing in comparison. I loved that I could work in GUI mode, save my session, go back home and resume my session in a terminal over SSH, which the exact same interface and keybindings. I quickly became very productive with Vim, and over the years have honed my plugins, settings and color themes to just how I like them.

But recently, I’ve been thinking about this again, and I might just reconsider Vim. I highly recommend reading these two blog posts to better understand where I’m coming from:

• From Vim to Emacs — Part I
• From Vim to Emacs — Part II

Don’t get me wrong — I think Vim still has a lot to offer. But, I can not deny that Vim is not what I would call a “forward looking editor.” Here’s why:

• Development community: the Emacs development community is a lot more open and vibrant right now than the Vim community. Part of this has to do with the BDFL model in Vim. Bram Moolenar has done a tremendous job in bringing Vim to the stage where it is. People can and have forked Vim in the past. But for one reason or another, Vim has stayed Vim, and its development trajectory has been slow and incremental.
• Source code: Vim’s source code is not clean. At all. I just briefly skimmed over the source tree for Emacs 23, and it looks a lot more understandable and well structured.
• Architecture: Vim 7 finally got spell check. But the spell check does not use any of the existing tools or formats. Vim has its own scripting language, with its own interpreter, grammer and data structures. Why not just use one of the many wonderful programming languages out there? Yes, there are interfaces to allow writing Vim code in Python, Ruby, Perl etc. But why reinvent the wheel all over again?

When Bram Moolenaar — the lead developer of Vim –  joined Google, I had hoped that Vim would generate a lot more interest and enthusiasm. But so far, it hasn’t changed much.

And so, in the next few weeks, I’m going to take another look at Vim as well as Emacs. I’ll try to do an objective evaluation of where the editors stand today, where I perceive they are headed. I hope to make my decision on whether to move away from Vim or not by the end of this year.