Enabling rich(er) interactions in the Clojure REPL

I love the Clojure REPL.  I’ve never been more productive in any other environment.  In particular, I happen to like the REPL and general development experience provided by Counterclockwise, the Eclipse Clojure plugin.

That said, the Clojure REPL is far from perfect.  A long time ago, I banged out this page describing what my ideal Clojure development environment would look like.  Much of what’s there is still an accurate reflection of my ideal end-state, and much of it is now available in Counterclockwise.  But, some things remain unfulfilled.

Like, when you are working with image data.  I do, all the time.  I’m parsing documents, producing rasterizations of them, performing all sorts of transformations and analysis on them, often in the REPL. Yet, I end up needing to have other tools around to do the simplest of things…like, oh, to look at an image.  Other fancier things should be possible, but let’s start with that and see where we end up.

This corresponds with this bullet in the aforementioned description of an ideal Clojure environment:

  • Configurable pretty-printing of output
    • This also means being able to “print” non-textual data, such as having images drawn inline into the REPL if so desired, etc.
    • See Factor’s REPL for an example

So, I implemented opt-in “rich content” Clojure REPL interactions in nREPL (a tool-agnostic network Clojure REPL server & client implementation), with a first spike of client support for such “rich content” in Counterclockwise.  The result is something that I think can be the basis for breaking a lot of new ground in how we use the [Clojure] REPL.

Video demo follows, with some discussion of the implementation and ways clients can add their own response types and such dynamically (direct link for HD video):

The code for this is currently on nREPL HEAD (the SNAPSHOT coordinates are [org.clojure/tools.nrepl "0.0.6-SNAPSHOT"]), and this branch of Counterclockwise (which, along with a couple of refinements, will hopefully be rolled into the next release). It’s all bleeding-edge stuff, so I’m sure there’ll be lots of change to come, but it’s a start.

Go poke and prod at my approach, let me know what you think — and, hey, it’d be awesome if someone knocked out rich content REPL  support for another tool, be it jark (which already uses nREPL), vimclojure, Enclojure (both of which are planned to use nREPL eventually AFAIK?), or others.

10 thoughts on “Enabling rich(er) interactions in the Clojure REPL

    1. That’s certainly an option in Eclipse / Counterclockwise (though the embedded browser on windows will be IE 7/8/9). It’s not actually ideal for my use case (the images in question are usually very large), but inline display is an obvious requirement at the end of the day. The polish of CCW’s support for this feature is definitely not there yet in any case (e.g. you’d want to be able to easily twiddle which content types you want to get “enhanced” responses for). Lots more to come. :-)

    1. I’m not personally familiar with CLIM, outside of what I’ve read on the ‘nets.

      That said, yes, that seems mostly right, if you follow things through to their logical conclusion. That kind of interaction depends heavily upon the REPL client in this case though. I’d certainly love to get more control over Eclipse from within Clojure at runtime (and that may come sooner rather than later given the changes being made to support such things in E4), which would enable all sorts of things.

  1. Looks cool! Any reason beyond simplifying the code for choosing your own set of strings rather than content types?

    1. If you mean, “why am I using simple(r) strings instead of MIME types?”, the answer is that I don’t (yet?) understand why MIME types are organized the way they are. e.g. why image/png instead of just png? I appreciate the utility of namespacing in general, but I see stuff like image/vnd.adobe.photoshop — where the content subtype is using an ad-hoc namespacing mechanism anyway. Thus, I’m OK with starting out with simple strings like png, txt, mp3, etc.; and, if something more complicated is necessary, people can go ahead and use traditional MIME type strings (which can be integrated into the render multimethod’s hierarchy just as easily).

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s