Over the last few months, I’ve been learning a lot about a text editor called Emacs. I haven’t started using it full-time, yet, but I’ve already spent dozens of hours researching it. The reason that so much information even exists is that Emacs can be easily extended to do things far outside the domain of a simple “text editor”. This is done using a programming language called Emacs Lisp (one of many dialects of Lisp). The essay I’ve linked above, The Lisp Curse, proposes the following hypothesis: “Lisp is so powerful that problems which are technical issues in other programming languages are social issues in Lisp.” Since Emacs is written in a dialect of Lisp, naturally it seems like it would fall prey to this problem.

The Past

        I can’t really evaluate the essay as to how it treats Lisp historically. But what strikes me about it, as someone who (currently) isn’t fluent in Lisp, is how much it reflects what I’ve seen in Emacs. The EmacsWiki is nothing if not a historical archive of many years of Emacs development. If you go to the page for some high-level problem, like session management, you’ll usually have at least three competing solutions. The trouble is that many of these solutions haven’t been touched for years, and may even be broken in modern Emacs. A different solution (which may not be perfect) may have been added to the standard distribution in a recent version, making extra code unnecessary (electric-pairs comes to mind for auto-inserting pairs of characters like [] and ()). This has been the case for the history of Emacs pre-2011 or so - let’s call this the “Dark Age of Emacs”. It seems to me that projects from the Dark Age of Emacs suffer from The Lisp Curse. From the essay:

“Programs written by individual hackers tend to follow the scratch-an-itch model. These programs will solve the problem that the hacker, himself, is having without necessarily handling related parts of the problem which would make the program more useful to others. Furthermore, the program is sure to work on that lone hacker’s own setup, but may not be portable to other Scheme implementations or to the same Scheme implementation on other platforms. Documentation may be lacking. Being essentially a project done in the hacker’s copious free time, the program is liable to suffer should real-life responsibilities intrude on the hacker. As Olin Shivers noted, this means that these one-man-band projects tend to solve eighty-percent of the problem.”

        I ran into this problem pretty early into my Emacs career. Session management was one of the first things I wanted to figure out when I started with Emacs. My goal was to keep a small text file open on the side at all times, containing a list of shortcuts and tricks I should remember. Imagine my frustration when none of the solutions I tried actually worked! Or at least, none were simple to set up for a complete beginner. Right now I use revive.el, which functions for the most part, but I’m not entirely happy with it. I could probably get it working if I understood it better, but at the moment its particular 80% solution works for me.

        Code from the Dark Age of Emacs is kept in blog posts, hosted on EmacsWiki, stuck in some obscure directory on university domains, lost to the ether that is personal websites with expired hosting… Tracking down updated versions is nigh impossible, because they’re often created by new authors taking care of an abandoned project. Small projects get “forked” or maintained by someone new without the benefits of the trail of crumbs left by forking on GitHub. I once ran into a project that was three times removed from its original author, with every successive version being hosted on a different personal website. The only reason I found the “newest” version of the project was a few stray comments on a long EmacsWiki page, full of hacks and monkey-patching that stopped being relevant years ago. See the EmacsWiki page on smooth scrolling for an example of this - odds are that none of those fixes will work for you. I’m surprised even two comments on that page have version numbers to serve as a lame time stamp…

The Present

        It’s been a long time coming, but the Enlightenment of Emacs has begun in earnest, thanks to the power of the internet and proper tools. GitHub makes it incredibly easy for developers to collaborate on large projects, or for users to report bugs and have them fixed quickly. The Emacs Lisp Package Archive, and especially the inclusion of package.el in Emacs 24, have made installing and distributing extensions as easy as it should be. The MELPA repository combines the power of the two by supporting packages stored on GitHub, without requiring the author to upload their package to a special repository or give ownership their code to someone else. Unlike, say, downloading revive.el, trying a new package doesn’t mean downloading some files off of a Japanese server. While bad documentation mostly plagues code actually hosted on EmacsWiki, GitHub encourages everyone to have a bare minimum of non-technical documentation (do this to start using it, here are some things you might want to tweak). Collaboration on a single perfect solution is easier than ever before, and life is pretty good for both developers and users.

        Here’s a somewhat abstract problem, solved with flying colours by collaboration: when programming, you often want to select some chunk of code and do something with it. Usually, this is a “semantic” chunk - in prose, imagine selecting a word vs a sentence vs a paragraph. You can see a video of this in action here, and see for yourself how awesome this actually is. I can’t track them down any more, but I saw at least one “80%” solution to the same problem by Xah Lee, and another somewhere else. This is the Dark Age of Emacs at work - nobody knew what anyone else had developed.

        Magnar Sveen’s expand-region.el is, as far as I can tell, a nearly perfect implementation of selecting semantic units. Better yet, it’s not limited by his imagination. If you scroll down, you’ll see that there are at least eight other contributors to expand-region. If you scroll up, you’ll see there are many specialized X-mode-expansions.el files. If your language of choice isn’t supported, contribute! And now there’s a definitive solution to this problem.

The Future?

        I don’t know, first-hand, how things stand for Lisps other than Emacs Lisp. Or whether this is going to be true for new dialects of Lisp going forward, thanks to new tools. From reading people’s reactions to the essay on HackerNews (in two different threads!) and Reddit, it seems like the problem is real… depending on who you ask. The fact that it’s so easy to solve problems, everyone does it their own way had at least one piece of anecdotal evidence in its favour. Lots of people disagreed, obviously.

        Points in favour of thinking this may not be true going forward: a lot of people threw in a vote for Clojure, a newer Lisp dialect that runs on the JVM (which has definite overlap with the Emacs community). I’ve seen some pretty cool tools (lieningen, Light Table - no surprise that the two work together) and libraries (Noir for web development, Overtone for making music) for Clojure, and they’re all hosted on GitHub. Perhaps programmers finally have the social tools we need to avoid not invented here syndrome and the other composite parts of the Lisp Curse!