Andreas Jacobsen's Distraction

Google doesn’t return any useful links for this, so here’s where to find the NetBeans cheat sheet:

I’ve spent some time looking at Emacs Lisp lately and there’s a weird ecosystem going on there. ELisp (and I’m thinking primarily about Emacs configuration here) tends to grow organically, because it’s paced by a person’s learning of the editor. Every now and then someone needs a new function, and they either search or ask around for something similar. Either it’s been implemented before and the code can be copied into their local Emacs configuration or they can write a simple version that is sufficient for initial usage.

The way I tend to grow my Emacs is either piecemeal, as described above, or by reading other people’s code. Sharing Emacs configuration code is a long tradition, and there are many webpages dedicated to it (DotEmacs, there are plenty on the Emacs wiki and ELisp is the 11th most used language on GitHub). Reading someone else’s Emacs configuration is a great way to get new ideas. Recently I’ve found djcb’s dotemacs (he also runs an interesting blog called emacs-fu) and the emacs starter kit very interesting.

In particular, I noted two things. In djcb’s dotemacs, he defines macros for conditional requires, that degenerate gracefully when required libraries are unavailable, instead of erroring. It similarly has a macro when-available, that runs some code if and only if a given function is available. These are used liberally throughout his configuration, making it robust against unexpected environmental differences. When I first saw this I considered it clever (and still do, really) and wondered whether I should include something similar in my Emacs configuration. In the end I decided against it, because I only use Emacs in very similar versions on two machines and version control libraries that are missing from either or both systems. This ensures that I rarely see errors from missing requires or functions.

In emacs-starter-kit the use of ELPA, the Emacs Lisp Package Archive, intrigued me. I’m a big fan of package management, though I tend to be of the ‘one package manager to rule them all (per system)’ crowd. Using ELPA instead of (re-)versioning all the external code I use seems like a good idea, though I’ve put it off for a bit due to the number of comments to the effect of ‘workaround for bug in ELPA’ in the starter kit. I’d also like a web interface to browse available packages and accompanying source so I can check on the status of all the libraries I already use.

Thinking about both these things, gracefully accepting the limitations of environment and package management for dependency resolution, I started to wonder about other best practices for ELisp. While Emacs is a huge framework in and of itself, the incremental improvement pattern for building ELisp doesn’t exactly invite to build other frameworks. So I wasn’t very surprised when I found that the only unit testing framework is quite new and not generally accepted as the right way to test ELisp (discussion here).

None of the advice or ideas I’ve found have really addressed the practice of writing ELisp, maybe with the exception of Steve Yegge’s save-excursion post. Even people who talk about modularity don’t generally mention how to best organize ELisp modularly. This isn’t necessarily bad. The lack of clear practices does mean one has to make a lot of judgement calls on what the right thing to do at any given point is, taking into account the one’s own requirements and limitations.

So it seems the Rails community is looking at alternative editors. This post by Daniel Fischer gives a pretty good overview. I have to say I approve. Not that TextMate isn’t good. It is. But it’s very cool for Emacs (and Vi!) that a community that focusses a lot on sharing knowledge and techniques is taking up these editors.

For me this video on ido-mode was a big win. I’m also a fan of the Emacs in 5 minutes demo, and there are many more here. There are also a couple blog posts going around on experiences with both vi and Emacs, usually comparing them to TextMate. What these three have in common is composability and scriptability. I constantly butt my head against the lack of it in fullblown IDEs. Eclipse, which I spend a bit of time in from day to day, doesn’t even have any decent support or plugins for keyboard macros. It’s so easy to forget when dealing with editors that recognize ASTs that programming is fundamentally about editing. Sure, the stuff that we can do with refactoring tools is impressive, but if it’s taking focus away from thinking about how you can do your own refactorings, it’s probably hurting as much as it’s helping.

Here’s some emacs stuff I use regularly. My dotemacs stuff is available at github if anyone’s interested.

• ido-mode – A minor mode that makes many functions autocompleting. My favorite little touch is how it looks at recently opened files when trying to autocomplete filenames. I use this to look up configuration files deep in Java projects quite a bit.
• tramp-mode – Open files over almost any remote (or local) protocol. The linked page has find-alternative-file-with-sudo that opens local files with sudo, which is nice.
• yasnippet – Obligatory snippet minor-mode. I’m not a huge fan of the default binding to tab, so I’ll need to find a better one eventually.
• nxml-mode – A superior editing mode for XML and XHTML. I don’t even use this properly (yet), and it’s still superior to Eclipse’s default XML editor.
• Various language modes – There’s a fantastic major-mode for Erlang. There’s a great one for Scala (superior to anything I’ve seen in an IDE with one caveat: I can’t get maven projects to compile correctly, yet). I haven’t tried out js2-mode yet, but I’ve heard good things. In general people create these for Emacs sooner and better than many IDEs (though some of the NetBeans 7 stuff looks impressive.)

I use Emacs on Ubuntu 8.10, where I use emacs-snapshot-gtk, which is a stable snapshot from CVS. On Mac OS X I use Carbon Emacs, though I’m probably going to move to a build of Emacs.app next time I upgrade. Carbon Emacs is pretty good, but has a couple of weirdisms that I don’t like. For example, the zoom button doesn’t fill the screen, it just makes the frame 80 columns wide (fixed by max-frame).

While I’ve taken a couple potshots at IDEs in this post, I’d like to emphasize that while there is a difference in philosophy, and I adhere to the “editor first, code manager second” philosophy, but the IDEs are getting there. The editors didn’t just start out awesome at editing, and the IDEs didn’t just start out awesome at code managing. Both of them are constantly improving and the choice for the future isn’t necessarily clear. All in all, I’d say it’s a good time for both of them. More people are diversifying, both between editors and IDEs. This is a good thing too, as it’ll drive improvement further.