beatworm.co.uk

I’ve always enjoyed the sound of the banjo. I’d noticed that lately it’s been cropping up more prominently in music recordings I’ve purchased, what with my penchant for ‘americana’, and burgeoning Sufjan obsession. For a while I’ve been kicking around an idea, based around a jokey list of a recipe for the ultimate band; chick on bass, handclaps, xylophone, accordion, etc. and the banjo seemed to also have promoted itself to this exclusive set. Imagine my joy on Christmas day when I unwrapped a five string banjo. Perhaps I should say disrobed, rather than unwrapped, as my inventive wife had actually dressed the cased instrument in a full Santa costume, to better disguise the too-obvious-for-wrapping silhouette.

Some initial thoughts about the banjo, from an amateur explorer’s perspective.

• They are rather tricky to tune
• It’s tuned to a G chord, so it’s a bit like slide guitar
• The hard stuff is the right hand. I’ve always been a bit slack at my right hand guitar techniques, so this part is perhaps even more work.
• It’s very loud, everyone nearby gets to share your ineptitude

It’s very pretty to look at, and tuned up sounds superb. I’ve learnt four chords, and a basic right hand pattern, from a tution book I coincidentally recieved for Christmas, which bears a reassurance accross its cover, in large point type; ‘NO KNOWLEDGE OF MUSIC REQUIRED’. It is quite possibly the best Christmas present I’ve ever received.

Since I switched to using Macintosh predominately, I’ve tried a few different programs for editing text. I auditioned some of the available Macintosh native applications. The built in text editor, “TextEdit” is surprisingly useable, although it no longer offers much specific programming support. XCode has a capable editor, with IDE features for Macintosh application development, but it’s too slow and large to be more generally useful. The power editor on Macintosh always used to be “BBEdit” , but it’s expensive, and seemed complicated and old-fashioned. TextMate is very interesting, an attempt to bring together UNIX editing concepts with the OS X application frameworks, and I was nearly tempted to switch to it full time, but I eventually decided to stick with the editor I know best, GNU emacs .

It turns out that that’s not as straightforward a decision as it might seem. There’s a variety of different emacs implementations on offer. Apple ship a version of emacs 21 in /usr/bin , but it’s purely a terminal based application that has to run in an emulator window. This works well enough, but has restricted font rendering, and your editor session isn’t an application instance at the top level, being subprocess of the terminal application. You could compile a GUI emacs using the Apple X11 server, which improves the font handling, but still would be a sub-application process, and would introduce the usual klunky X11 clipboard integration . There are also a few ‘native’ Emacs application ports. Andrew Choi has ported both GNU Emacs and XEmacs to the Macintosh OS X carbon APIs, and there is something called “Emacs.app” which is an update of the NeXT Emacs port to a more modern emacs base.

I seem to have settled on using the Carbon emacs port, in a new variant that uses the ATSUI text rendering framework rather than QuickDraw . This seems to fix some of the very ugly font rendering behaviour I used to sometimes see with Carbon emacs. I suspect I am probably rather oversensitive to font rendering accuracy. I think this new engine is only available in the CVS tree for emacs, but this is quite simple to install on a Mac using MacPorts .

sudo port install emacs-devel +atsui

A remaining niggle is the use of emacs in server mode. Emacs is rather a heavyweight application, taking some seconds to load, and it carries a lot of state. Ideally you want to perform all of your editing in a single emacs session, rather than starting a new editor anew each time. Emacs has a client/server mode to allow you to do just this. Simply add

(server-start)

to your .emacs file to start the server, and use the emacsclient program as your editing tool. This contacts the running server and creates a new buffer for the invoked editing context. Setting your environment variables for EDITOR and VISUAL means that shell commands will use the emacs server as your default editor.

The niggle is that you then have to switch window context to edit. And as autoraise and raise-window do not seem to have any effect on Carbon Emacs, you have to manually find the emacs window for the server that is waiting for your edits, probably buried under a pile of windows. I’ve managed to go some way to fixing this problem with an unholy marriage of elisp and AppleScript.

The AppleScript

Tell application "Emacs" to activate

will raise the running emacs frame and switch focus to it. There is a command line program provided with OS X, osascript that can run AppleScript programs from script files, or run one-liners via the -e argument. It is therefore possible to add some elisp to the emacs initialisation scripts to automatically run the AppleScript snippet.

(defun my-server-visit-hook()
       (interactive)
       (shell-command
	  "osascript -e 'tell application
	     \"Emacs\" to activate'"))

(add-hook 'server-visit-hook 'my-server-visit-hook)

Every time a server buffer is created, this hook will be called, and emacs will raise itself to the front of the window stack, steal focus and prompt for input, which seems to be mostly what I’d want. I have yet to devise a manner of returning to the calling window context after editing, which will probably be a less trivial hack.