Category Archives: emacs

emacs, node, javascript, oh-my

1 Reply

Each time I turn my attention to using JavaScript I’m a bit taken aback by how tangled the Emacs tooling is. So here are some random points I discovered along the way.

Of course there is a very nice debugger built into Chrome, and that does a lot to undermine the incentives to build something else in Emacs. I only recently discovered there is a more powerful version of that debugger.

Safari and Chrome, because they have Webkit in common, can be asked on start-up to provide “Remote Webkit Debug” connections. You invoke ’em with a switch, and they then listen (i.e. open -a 'Google Chrome' --args --remote-debugging-port=9222). Bear in mind that this Debug protocol is quite invasive, i.e. it’s security risk. Having done that it’s fun, educational, and trivial to look at the inside of your browser session, just visit . Tools that use this protocol use the json variant rooted at .

One thing that makes the emacs tools for working on JavaScript such a mess is that there are far too many ways to talk to the java instances, and then there are multiple attempts to use each of those. So there are two schemes that try to use remote WebKit debug pathway: Kite, and jss (also known as jsSlime).  I’ve played with both, and have them installed, but I don’t use them much. Both of these are useful in their own ways, I developed a slight preference for jss which has a pretty nice way to inspect objects.   Though I’m on the look out for a good Emacs based JavaScript object inspector.

There is a delightful video from Emacs rocks explaining yet another scheme for interacting with JavaScript from Emacs using swank-js.   What’s shown in that video is a wondrous and a bit mysterious.   The mysterious bit is that it doesn’t actually make it clear what the plumbing looks like.  I’ll explain.

Slime is a venerable Emacs extension originally developed to interact with Common Lisp processes.  It does that via a protocol called swank.  Which means that unlike, for example, emacs shell mode there is a real protocol.  The sweet thing about slime/swank is that it provides a wide window into the process enabling all kinds of desirable things, at least for Common lisp, like:  inspecting object, redefining single functions, debugging, thread management, etc. etc.  In the video you can he’s managed to get a swank like connection into a browser tab and this lets him define functions and dynamically tinker with the tab.

The plumbing is wonderfully messy.  A node.js process acts as an intermediary.  Bridging between swank (for the benefit of Emacs) and a web socket based debugging protocol for that hooks into the browser.  I assume that web socket protocol is similar, if not identical, to the remote WebKit debug protocol.  In the video the Emacs command M-x slime-jack-into-browser establishes the pipeline, and reading that code is enlightening.

A consequence of that design is that the resulting emac’s slime buffer is actually interacting with two processes.  A node.js process and the JavaScript in the browser tab.  You can switch between these.  I find that goes wrong sometimes, and it took me a while to discover the slime command (slime command start with a comma) “,sticky-select-remote”.  If you hit tab it will list the things you might talk too.

The swank-js github instructions are pretty good.  And they explain how to uses swank-js with node.js – though that assumes your reasonably comfortable with node.js already.  I don’t actually follow those instructions.  Instead, after including swank-js in my projects’ dependencies, as the instructions suggest, I require('swank-js') in my main module (only when in a development mode of course).   It’s worth noting that when you then slime-connect to your node.js program you’ll be in the global object.  Your actual program (usually found in the file server.js) will have been wrapped up in a function and hence it’s locals variables are invisible to you.  I work around that by putting interesting state into an object and then do something like global.interesting = interesting.

Recall the remote WebKit debug protocol?  There is a clone of that for node.js known as node-inspector.  Use it!

I have yet to try two other Emacs/JavaScript interaction packages.  slime-proxy and skewer.

If you don’t use slime already you might be able to install these using the usual Emacs package repositories.  I ran into problems with that because I use a very fresh slime/swank and the Emacs package system wanted to bless me with older variants.

Hope this helps.

 

emacs w3m about pages

Leave a reply

If you use w3m within emacs you might be interested to know you can do this:

(defun w3m-about-foobar (&rest args)
  "Hang a emacs generated page on this url: about://foobar/"
  (insert
    (format "<p>This is so exciting, you have %d buffers!</p>"
            (length (buffer-list))))
  (insert "<img src=\"http://ergoemacs.org/emacs/i/emacs_learning_curves.png\"/>")
  "text/html")

Which means you can build entire pseudo web sites that are local to your emacs :).

I got to wondering about how I might do this because I use w3m to view Lisp documentation[1], and I have this little slime contribution (slime-documentation-search.el) that adds an easy way to search quickdocs.org.  As you can see if you look there are at least four alternatives to quickdocs.org; and I’ve been wondering if I could puzzle out a way to create little website that would let you browse between them.

The trick above looks like it could help, but the obvious approach doesn’t work because w3m doesn’t support iframes.  Exercise for the reader, I guess.