One Last Emacs Try

I am a Vim user. My first real in-depth experience with Vim came in graduate school when my Ph.D. advisor sat down, opened a text file containing the output of a genetic screen, and started manipulating it with lightning speed. When he finished, he handed me the venerable O’Reilly “Vi in Nutshell” book and left me to it.

While bioinformatics only bears a passing resemblance to programming, what they share is the need to manipulate large text files very quickly. Vim soon became a key tool in my research toolchest, and I have been a Vim user even since.

That’s not to say that I’ve never used another editor. When I first started using Linux in high-school nano was my editor of choice, thanks to its extremely shallow learning curve. When I started working with Ruby on Rails, I set aside Vim in favor of TextMate, as it was the overwhelming choice of the community at the time. I’ve worked side-by-side with programmers that swore by BBEdit, and when the situation has called for it I’ve used everything from Xcode to Eclipse. I’ve even dabbled with the newest generation of editors such as Atom and (my personal preference of the bunch) LightTable.

I’ve even used Emacs. Once I switched to Emacs for a 3 month stretch, mostly just to see if I could. Still, with all this varied editor experience, when I return to Vim I just feel more comfortable, more productive. Certainly, this is largely due to experience, but I can’t help but feel there might be more to it than just that.

Not Another Editor Post

If there’s anything the world doesn’t need, it’s yet-another-editor-comparison post. So, this is not one of those. Instead, I intend to do something of an experiment with myself as the subject. For at least the next two weeks, I’ll use Emacs. I’ve dusted off my .emacs.d/init.el from the last time I worked with Emacs, and posted it as a Gist here. For reference, I’ve also posted my .vimrc here.

If you glance at those files you might notice two things. First, I have more plugins in my Vim config than I have for Emacs, even though I’ve been working to minimize the number of plugins that I use with Vim. When it comes to the development and distribution of editor enhancements, I feel that Vim still has a bit of an edge over Emacs. To some extent, I suspect this might be a carry-over of the Lisp community’s somewhat insular, why-use-a-library-when-I-can-just-code-it-myself attitude. To be fair, both Emacs and Vim have made great strides in this area in the last couple of years.

Second, a decent chunk of my Vim configuration deals with integrating Vim with the rest of my day-to-day workflow involving tmux and friends. Before even beginning this experiment in earnest, I already know that this will be something of a sticking point for me. Regardless of editor preference, I am a big fan of the “Unix philosophy” of single-purpose tools used in combination. I fear this already puts me at something of a disadvantage when it comes to Emacs and its “everything and the kitchen sink” approach. That said, I look forward to being able to code around this barrier in a Lisp (even if it is Emacs Lisp).

As I go through this experiment, I’ll do my best to write down a little about how I’m doing, where I’m running into issues, and what I’ve done to work around them. I still suspect that I’ll reach the conclusion of these two weeks and return to Vim, but at least I’ll have tried (again).

Why Emacs?

I’ve been using, and customizing, and being comfortable, happy, and productive with Vim for over 11 years now, so why consider a switch? To be honest, I’ve always been a bit on the fence when it comes to Emacs. I love that its written in a Lisp, though I’m not particularly a fan of Emacs Lisp. (My desire for a Emacs clone written in Clojure is the main reason I’m a fan of LightTable.) I really like that Emacs is completely open to extension, and that it can be scripted in the same language in which its written, but I loath its bulk. In a perfect world, I’d love to have an editor with the size and speed and community of Vim, but the lispy-ness, interactive features, and extensibility of Emacs.

If you are a veteran of the editor wars, you may notice that I’ve left out modal editing. For the uninitiated, Vim has a strong concept of different “modes” that separate the tasks of navigating, selecting, and writing text. I’ll be blunt: I agree with the Vim crowd that modal editing is a superior approach to working with text. So will I, as my friend Arne Brasseur suggested, use Evil mode to gain the advantages of modal editing in a Lisp-based editor? In a word: no.

The last time I seriously considered usage of Emacs I did enable Evil mode, but about a week in I disabled it. It suffers, unfortunately, from the same problem as every Vim emulation I’ve ever tried, from OS X input hacks to NetBeans plugins and more: it’s not Vim. It might be hard to understand, and it’s even harder to explain, but Vim benefits from being built around the concept of modal editing from the ground up. When you are in normal mode, you’re moving through text. When you’re in insert mode, you’re editing text. Vim very thoroughly compartmentalizes these different modes. Once you grok this, you’ll never make the mistake of attempting to move through text in insert mode using a key-combination from normal mode. What’s more, modal editing means that key-combinations can be overloaded. For example, I’ve configured Vim so that ctrl-d moves me down half-a-page in normal mode, but does character-wise delete-forward in insert mode.

Emacs (and Xcode, and NetBeans, and all the rest) were not built around the modal editing concept, and so attempting to overlay modal input on top results in a very leaky abstraction. For example, I like using ctrl-h in place of backspace. In Emacs, the default mapping for ctrl-h is to run the help command. Now, I could turn on Evil mode, map ctrl-h in insert mode to backspace, and re-map ctrl-h in normal mode to the Emacs default of help, but doing so quickly results in remapping most, if not all, of Emacs’ default key-combinations to work with my modal mindset.

Instead, I’m going into this little experiment with every intention of embracing Emacs as Emacs, and not as an alternate implementation of Vim. Yes, this does mean that moving through text will be more painful. Yes, it does mean that I’ll have to un-learn my nervous habbit of tapping j-k-j-k when trying to think of the next thing to write, but that might not be all bad. I half-suspect that I use these nervous habbits of moving around in normal mode as a subconcious excuse to avoid really thinking about what I should be writing.

Why Now?

Well…why not? Actually, the answer to this question is as trivial and arbitrary as you might expect. Not so long ago I was working with some Clojure code, and I noticed that I fairly frequently refactor a long string of method calls to use Clojure’s threading macro. That is, I’ll start off with something like

(map find-things (list-items))

then modify it to

(filter my-predicate (map find-things (list-items)))

…and on

(partition 2 (filter my-predicate (map find-things (list-items))))

…and on

(map hash-map
     (partition 2
                (filter my-predicate
                        (map find-things (list-items)))))

This is far easier to read in threaded form

(->> (list-items)
     (map find-things)
     (filter my-predicate)
     (partition 2)
     (map hash-map))

but I usually don’t realize that I’d rather have it in this form until after I’ve created the parenthesized mess above. Unfortunately, even using all of my modal-editing Vim magic, this is a fairly cumbersome refactoring to perform. In other words, this is the perfect case for an automated refactoring.

Lo and behold, a tool to do just such this sort of automated refactoring does exist. And, yes, as I’m sure you’ve already guessed, it’s an Emacs plugin. I’d much rather have this writen in Clojure itself, and in fact there is a Clojure library to do this sort of thing, but it’s not been touched in a while. I figure that whatever loss in productivity I might suffer over the next two weeks of using Emacs would be equivalent to the amount of time I’d spend updating that library, so here we are. Maybe I’ll actually like Emacs this time, and it will be time well spent…

Actually, to be perfectly honest I wasn’t going to switch back to Emacs even after all that, but then I saw Arne’s tweet that the Emacs Berlin group will be 1 year old this month, so…Happy Birthday Emacs Berlin! Maybe when this little experiment is done I can convince some of you to try Vim for two weeks. ;-)