For many years, Emacs has had client-server support so that you can leave it running all the time while allowing external applications to open files in it as needed. But that doesn’t work with GUI applications on the Mac, since they generally don’t know how to call an editor using the shell. Instead, most Mac apps that support external text editors use the ODB Editor Suite created by Bare Bones Software, which extends the normal Mac “open file” event with the ability for the editor to tell the calling app when it’s done.

Support for the ODB protocol isn’t built into Emacs, but it’s basically the same as using emacsclient from the shell. So without further ado, here is “EditorClient”, a small shim application which acts like an ODB editor but actually opens files in Emacs. All it does is intercept the “open file” event and call emacsclient. When you’re done editing the file (C-x # or server-edit in Emacs) it responds to the ODB client application which can then update its contents. If you use a non-Mac port of Emacs for some reason, you can probably also associate files with it in the Finder to make for easier double-click editing. (The Mac ports of Emacs can do that themselves; they just don’t have the special handling for ODB events.)

This is really sort of a quick and dirty hack; it’s only for Leopard and the emacsclient call is hard-coded to use the one in the /Applications/Emacs.app bundle. I’ll try to improve it later, but I’m posting it now in case anyone else out there is looking for something like this.

Download it here: EditorClient.zip (20.98 KB)

I hadn’t expected my first substantial Ruby on Rails project to be for someone else, but that’s how it turned out. For the last couple of months I have been working on a Rails-based update of The Gadgeteer (note: if the site you see is blue and white with small fonts and table-based layout, the DNS change hasn’t propagated yet; try this link instead, but please don’t bookmark anything using that URL) and it rolled out tonight. Full disclosure: I didn’t do the visual stuff, because I’m not really very good at that; another designer created the new look, and I converted it to templates in my Rails application. More full disclosure: it’s not really done, and any rough edges will be smoothed in the next week or so.

This is an interesting project for me, because it is essentially a custom-built content management system which is a little bit like a “real” CMS, a little bit like a blog, and a little bit like nothing else. The original Gadgeteer site was managed with custom PHP which has, over the years it has been running, accumulated a lot of cruft. At the same time, the data model and features of the site, and the way its owners are used to working, have grown in ways that don’t quite fit the usual CMS or weblog models. This redesign is an opportunity to start from scratch, with the benefit of all of that accumulated knowledge.

Based on the time I have spent developing the new site so far, I think I can safely say that it was easier to code a custom CMS in Rails, in this case, than it would have been to hammer a prepackaged CMS into shape to do things the same way. I am not prepared to claim that this has any larger meaning at all, of course — this project was made easier by the fact that the public face of the site is not interactive and the back end will only ever be used by two specific people. But I wonder how many other site ideas fall in the nebulous space wherein a weblog application isn’t enough, but a full CMS is too much — it is so easy to develop in Rails that, in cases like this, there may not be any point in trying to mash an idea into the mold provided by existing software.

In the long run, this means more knowledge of Rails for me and better support for Rails on NYIP, both of which mean I’ll probably start programming for pleasure again. First up: a custom CMS-ish thing for online writing, hopefully ready in time for NaNoWriMo 2005. Or maybe a meta-journal/writing app/blog client/personal information repository. Or an AJAX-based web app for tracking my video game collection. Hmm, perhaps I better decide where to start…

Although I generally try to avoid anything in direct proportion to how much hype and attention it receives, I have decided to ignore that policy in the case of Ruby on Rails, the new web framework that is gaining mindshare as a killer app for the Ruby programming language. I’ve got a Ruby book, installed every Debian package with “ruby” in the name, and started working on my first Rails application. Or perhaps I should say… written a mostly-working Rails application in one day that I can now tweak to perfection. So far, I am impressed enough that I plan to use Ruby for future personal projects, perhaps instead of Python.

Ruby on Rails is, in essence, the Cocoa of web applications. Cocoa provides scaffolding for GUI apps with default behavior that is configured declaratively — that is, you build an interface and it does, as much as possible, the right thing, leaving you to develop only your application-specific code. Rails does the same for database-backed web applications. The comparison extends deeper, in my opinion, because both Cocoa and Rails — despite not being the most popular, buzzword-compliant option — take ease of development to a level not equalled by most of the competition. It’s the small details, the tight integration between all parts of the system, the subtle ways it always seems to do the intuitive thing.

Mind you, I don’t believe some of the hype, specifically that Rails couldn’t have been done in any language except Ruby. In particular, I think an equally easy to use web framework could be done in Python — but it hasn’t, yet, and I don’t really want to wait. (In a lot of ways, Rails resembles the sort of framework I was building piece by piece out of a combination of Quixote and my own code. But I gave up on that, because I really don’t enjoy having to build infrastructure when it is in the way of my end result. What can I say, I’m lazy.)

My first Rails application is tentatively titled “NovelSpace”, and it will be a replacement for my current (private) story archive, but with eventual support for multiple users and collaboration. It is essentially a special-purpose content management system, organizing its content into “books” that contain chapters that can be edited individually. Its security model will allow for password protected accounts for writers and readers, it will track revisions, and it will use Textile and Markdown to convert plain, easy-to-write text to HTML for viewing or printing. In a lot of ways, it is an online version of Pyrite Writer, my personal writing tool — and in fact, I will probably integrate the two using a web service, so that when I save something I am working on, it gets posted automatically.

I’m shooting for an actual release of both of these things by NaNoWriMo 2005, and at the rate I’m going right now I could make it with six months to spare…