Artagnon's Presence

NOTE: I have no intentions of starting another editor war. Opinions expressed here are my own.

Over five years ago, I realized that using editors like nano and Gedit wouldn’t suffice. The need to learn a real editor arose as I wrote more and more code. By nature, I’m a minimalist. I hate clicky flashy bloated things like GNOME, KDE, Compiz, Beryl etc. Emacs is large, graphical and consumes eons of memory compared to Vim. I had also just learnt touch typing and was eager to put that knowledge to use. Emacs didn’t appeal to me at all with its complex META and CONTROL keybindings and its complicated GUI. Vim, on the other hand was small, simple, ran off my terminal and had very simple keybindings. I took to Vim immediately and progressed to become very good at it. Vim uses muscle memory heavily- once you’re that good at Vim, you don’t have to conciosly edit anything; fingers move on their own and it feels like Vim is reading your thoughts. It’s the principle concept as touch typing. Which is what makes it so hard to switch. It struck me that there was something about Emacs worth learning over a year ago, but I was never really able to use it.

I wanted to do so much more with Vim when I realized that it was crippled. Everyone seemed to be talking about those features being present in Emacs. Consider a simple task- editing a file over the network. In the Vim world, I’d ssh into the remote machine and copy my ~/.vimrc and ~/.vim over, praying that the same version of Vim is present on the remote machine. Then using screen (see GNU screen) sessions, I could resume work. In the development front, I learnt that Vim had lots of features hardcoded for C/ C++, but not other languages. In Python, I had to use indentation-based folding to select codeblocks. I wished that Vim behaved more intelligently and do context-specific tasks. A :make in C or C++ is not the same as the :make in Python or :make in LaTeX. Vim didn’t understand this.

Writing and debugging were also separated- I couldn’t really debug anything from within Vim. This wasn’t critical until I ventured out to learn a Lisp. In Common Lisp, writing code and debugging it are so closely related that it was impossible to keep switching between applications to do it. Everyone recommended SLIME (Superior Lisp Interaction Mode for Emacs). I tried to switch retaining the keybindings using tricks like Viper mode for Emacs, but to be honest, nothing really worked out. Purists encouraged me to use Emacs as-it-is without these cheap tricks. I kept looking for Vim equivalents for several tasks and kept failing.

Few people understand the real difference between the two editors. They go on and on comparing the number of keystrokes required to do equivalent operations. I did the same for some time until it struck me- Vim is a dumb text editor, Emacs feels like some sort of intelligent organism. No real equivalents like the Vim “vawy…p” existed in Emacs- why? because Emacs is more intelligent in that. Vim doesn’t understand what a “function” or “codeblock” is. It simply understands characters and lines. Vim is a superb dumb text editor, but nothing more. Emacs, on the other hand, seems to understand what you write and assists you more intelligently. It doesn’t require the basic text editing functions that Vim has at all. I’ll give you an example. Recently, M-z or zap-to-char function was introduced into Emacs. Initially, I was very excited about it, because majority of my commands in Vim were dt, df. Now, I rarely use the command. There’s little doubt about it- In my Vim time, I could have beaten any Emacs expert at basic text editing. Vim does it faster. Emacs doesn’t even have many of those keybindings.

Then why? Because I came to realize that programmers do a lot more than just basic text editing. Vim and Emacs assist the programmer in different ways. Vim helps the programmer save time on basic text editing functions while deserting him when he wants to do his compiling or debugging or even interact with an external application. Emacs, on the other hand, seems to understand the code and helps the programmer operate on code entities, rather than characters and lines. SLIME is easily the best development environment I have seen. Emacs interactions with external applications nicely. Even documentation is readily available within Emacs.

What gives Emacs its so-called intelligence? A major part is contributed by it minor modes. When I open a certain file, some specific minor modes get activated and keybindings invoke context-specific functions. I loved the context-specific help. In latex-mode, I could preview the document I was writing with the same keybinding that I used to compile lines in elisp-mode. The same keybindings mean different (but comprehensible and expected) things in different minor modes.

As I started using it more and more, I understood the true nature of Emacs. Emacs is actually just an elisp environment bundled with several snippets of code written in elisp. Every keybinding invokes an elisp function (ok, some are so basic that the functions are compiled in C. But there are few immutable functions like this). This allows it to be infinitely extensible. Today, there are several brilliant elisp programs like emacs-w3m, emms, eterm, rcirc etc. which allow users to do email, chat, browse the internet and do a lot more, right from within emacs. SLIME is also just an elisp application. In Vim, everything’s written in C and keybindings are hardcoded, which is what makes it rigid.

At the end of the day, I have realized that average programmers can be equally productive on both Emacs and Vim. The question is simple- do you want your editor to assist you with basic text editing or higher tasks? And as programmers become better and better at what they do, I personally feel that they require assistance with higher tasks and not basic text editing.