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.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)