Update on Emacs Chrome

In my spare time I’ve been mostly bashing away at trying to implement an edit server for the Emacs Chrome extension in Emacs Lisp. It’s taking longer than I hoped mainly as it’s the first time I’ve ever tried to use the Emacs Lisp Debugger and it’s fairly alien compared to the usual functional GDB’s of the world which I’m used to. The current version should be pushing canned response back to every edit request but for some reason it’s not working. Once the basics are working the rest is just cleanup 🙂

In the meantime I’ve pushed a few additional updates to the repo. The first makes the extension usable on multiple tabs by passing the “port” back to the XmlHttp handler. You would think being an Emacs user I’d be used to the first class function paradigm by now but it’s not something I really get a chance to use much in the day job. I’m not sure if:

function contentTalking(port)
{
    port.onMessage.addListener(function(msg, port) {
        handleContentMessages(msg,port);
    });
}

is the correct way way to pass parameters from the local function’s scope to the listener function’s scope but I’m not sure how else you’d do it. Certainly the pattern of declaring functions in-line seems to be very common in the world of Javascript (as well as Emacs Lisp via the lambda () directive). If you look at the earlier version of the code you’ll see my C habits come through, after all it’s just a pointer :-).

I’ve also tweaked the pycl.py edit server code to handle running on Python 2.5 as my work box is running a fairly old Hardy Heron. Anyway the latest results of my hacking can, as always be seen on github.

EDIT TO ADD: Well that seems to be working now. I was getting confused in my use of car/cdr which is probably a result of too much Forth when I was younger. They are not equivalent to grabbing the first and next bits off the stack. Specifically cdr returns a list, so you had better munge it to what you want if it’s not a list.