Archive for the ‘Lisp’ Category

How a Vim user converts to Emacs

June 21, 2007

For many years I thought that the heretics of the Emacs clan [1] were clearly insane – the followers of Vim were obviously following the True Path. And then I was snared by the dark side.

My primary motivation for starting to use Emacs was so I could use the Slime[2] Lisp debugger. One part of Slime resides on the Lisp side, and a larger part resides on the Emacs side as an interface. I worked on a project called Slim-Vim that tried to emulate the interface side of Slime in Vim. We started by integrating a Common Lisp system, ECL[3] into Vim and exposing some of Vim’s functions. Then we could code in Lisp. We managed to get a fair way there before running into painful problems. Vim is not designed to be easily extended. There is a lot of code in there that works in a strange manner (likely for performance/portability reasons), and we basically got stuck.

While working on Slim-Vim I needed to get familiar with what I was trying to provide, so I used Slime on Emacs. To get by while in Emacs, I enabled Viper mode – an Emacs mode that emulates Vi keys. There were a couple of things that I didn’t like about Viper, so I added a couple of functions. It was at this point that I had unknowingly set my path.

Lets look at my programming philosophy over this period of time (6+ months). At the start of the Slim-Vim project, I was very new to Common Lisp and still thinking very much in a C style mindset. The only way of working that I knew was the C way – compile/link/run. As I learned Lisp & tried to make Slim-Vim work I read a lot about software design using Lisp, about how open, extensible and malleable systems[4] are the best way to work. And I agreed, I couldn’t wait to start working with a Lisp system, with a proper editor (Vim) and a good debugger (Slim-Vim) – if only I could get Slim-Vim working.

As I got more disheartened with ever getting Vim to work properly[5], I tinkered with my Viper changes some more. I finally started to grok what these Lispers were talking about. I could edit my Viper changes and instantly test them, instantly see the effects. The open system that I wanted to work with was already right in front of me in the form of Emacs, but I hadn’t seen it! I was looking for something better than C, but it took me 6+ months to really see it. It’s hard to describe, and in-fact I’m not sure that you can really convince people that open systems are better – it is something that you really need to find for yourself.

The second factor for me choosing Emacs is that I want to work with open and dynamic applications. This means you should be able to inspect how the app works, tinker with it, see your results right away. You should be able to live in it. And now that I actually grok that it seems crazy to me to choose to use closed systems.
I used to be a Vim bigot, so I’m sure somebody will say that Vim can do all the things that Emacs can do. Maybe it even can. But it doesn’t have the same feel. If you want to know what an open, malleable, dynamic system is like – use Emacs & write some Emacs Lisp. Trust me, you won’t want to go back.

[1] –
[2] –
[3] –
[4] – I’ll post about open systems in the future.
[5] – If you’ve ever had the misfortune to mess around with Vim’s internals, you’ll probably understand why it is hard to change.