Bill Clementson's Blog

Customizing Emacs for Mac OS X - Part 2

Saturday, April 23, 2005

I recently commented on the customizations that I have been doing to Emacs now that I've switched over entirely to Mac OS X as my development platform. Following that post, I received a number of emails from other Mac OS X Emacs users, which I'll cover in this post.

David Reitter sent me an email pointing me to the AquaMacs Emacs distribution that he and Kevin Walzer have put together. They decided to package together a recent CVS version of the standard FSF Emacs with a range of different elisp packages and .emacs settings that different people have found useful in a Mac OS X environment. David describes what they did:

"What I did technically was theoretically pretty simple. I found, configured, installed, packaged a whole bunch of packages and code snippets from other people's .emacs (emacs configuration) files that contribute some functionality to make things really Mac-like. I did not modify the Emacs code itself - it's the Carbon Emacs compiled straight from CVS. A stand-alone package has been available for quite some time, but Kevin and I felt that it would be time to provide a complete binary build. So I would see this as a distribution of other people's and our code rather than our own invention."

"I was tempted to detect darwin via system-type, as you did, but I chose instead to look at `window-system'. That's because I occasionally like to ssh in to the Mac, and use Emacs from an xterm; I assume that I'd want different key bindings in that situation."

"Emacs has a certain way of doing things which is not the familiar way that one does things on Windows. Emacs users (and developers) like the way that it works, and are not liable to really get into another way of doing things, much less re-tool Emacs to be as highly compatible with the Windows (or Mac) as some people would prefer.

But it's worth remembering that Emacs is not a Unix program, and does not do things the Unix way, either. Emacs originated on systems that did not have any GUI whatsoever. It's keyboard interface is not even fully compatible with any of the keyboards used on computers today. Emacs is about as incompatible with Unix as it is with Windows or MacOS. It just gets away with it on Unix more easily, because Unix doesn't have such a standard GUI with attendant expectations. (And many Unix users do not like or accept Emacs, either!)

Emacs is for people who like Emacs (as opposed to people who like some other particular user interface culture or standard). It has some compatability features and concessions to the platforms that it runs on these days. The perception of the quality of those features depends on where the user is coming from. Users who are accustomed to certain standard interface guidelines tend to find Emacs bewilderingly difficult to use. Emacs users just sneer at them and say, "Can't you read? Why can you not deal with typing c-H T ?"

I'm a dyed in he wool Emacs user for over a quarter of a century, and have used many different versions of Emacs on quite a few different operating systems and environments, going back to the original one written in TECO. My favorite version was Zmacs on the Lisp Machine (more powerful and more flexible, although it used a linked lines model rather than a looking-at-cursor model, which I didn't like.) I wouldn't trade Emacs for anything, but the degree to which it is "foreign" and difficult for new users cannot be understimated. I don't consider Emacs's GUI features to be great, either in terms of functionality or in terms of usability (never mind look-and-feel compatability) compared to what's available on "modern" programmer's editors.

Some people have asked, "What's wrong with it, specifically?" This just goes to show how unfamiliar they are with the expectations that some of us are talking about. Emacs seems so overwhelmingly different, and it even appears to have such functional deficiencies, that these conversations are hard to get started. We can all come up with a laundry list, but it needs more work than that. And the response always sounds like, "What's wrong with just doing it be XYZ? How could you not have located that command?" It's very frustrating and demoralizing. I'm guilty of being on that responding end of that, although I occasionally play the proxy plaintiff here (especially if I've recently been teaching someone to use Emacs recently). The degree to which Emacs advocates fail to appreciate this just goes to show how entrenched in our own cultures we all are.

The Emacs culture tends to include an aggressive exploratory style that is not oriented around GUIs. It's more natural to people coming from Unix, who are used to a command-line based environment that has a lot of nooks and crannys that need exploring. The Emacs culture is also very pragmatic, willing to go quite far in accepting some superficial warts in trade for what they see as access to underlying power. That's a value that is also shared by the Lisp community, by no small coincidence. Finally, there are differing aesthetics: lots of us Emacs users consider the normal GUI-oriented way of doing things on these platforms to be abysmal.

I have thought about Emacs in some detail over many years, but I don't see much payoff for anyone in my going into it in detail in this forum. So I won't usually talk here about specific design issues. I'll just try to garner some sympathy for the "newbies" here by pointing out that while there's no more experienced Emacs user than myself, I often sympathize with them. If Emacs weren't such a wonderfully productive environment, I'd be embarrassed for it, rather than promoting it as I do.

So I guess this post is about all the Emacs flaming I'm going to do.

My advice for people responding to Emacs complaints would be to not bother trying to defend Emacs or explain its culture. Just give as straightforward technical "how-to" answer for specific questions. Let the newbie just collect and process the help -- if they're too recalcitrant to deal with that, there's no hope for them anyway. Also point out that Emacs is certainly not necessary for programming in Lisp. Try to avoid comparing Emacs to a GUI-based IDE, but tell them about the specific Lisp integration commands that may not be available in their favorite editor. Try not to hitch Common Lisp to Emacs; that's a lot to swallow for someone brand new. Point newbies coming from IDE backgrounds to the trial versions of the commercial Lisp environments if you want to give the most polished first impression. Save SLIME for the hardcore folks, at least for the time being. "