This is beyond my wildest wishes. Meaning I have wished, as a formerly active Vim plugin author now fully switched over to Emacs/evil, exactly for Clojure compiling down to VimL so that I could maintain my plugins as Clojure/Lisp code, compiling it to actual VimL for public consumption, as a preprocessor. I'd think that would mostly do away with runtime performance worries, and not require the plugin user to actually have TimL installed as a plugin. Which means it could ease the transition of plugin authors to TimL, until eventually it's ok (and perhaps performant) to have it as a runtime.<p>Needless to say, I love the fact that Tim Pope has hopped on the Clojure bandwagon, that the community can enjoy well thought out tooling such as he did/does for Rails.<p>That said, tpope is one of only a few driving forces over on the Vim side of Clojure, whereas most seem to flock to Emacs. So I see this as potentially a great opportunity to eventually have Clojure-ish compiling/running on both Vim and Emacs, so that plugin authors can literally write and keep a single codebase that maps into the respective editor APIs. Well, least common denominator I guess, with extras specific for each editor. And maybe, speaking from my experience developing Vim plugins and looking into Elisp code, we will need 'clojureditor' packages providing higher level functionality painstakingly implemented for both editors, since it would be plenty non-trivial code that probably doesn't belong in a core like TimL neither in a Clojure+elisp equivalent.<p>Then you could see this actually taking off big time since the more voluminous Clojure+Emacs community would be writing a good deal of plugins which would also work on Vim for free (imagine that!), so that they could support both platforms because it wouldn't be much extra effort. Hats off to the Pope for actually taking on the arguably tougher half, since Elisp should hopefully be an easier target for a lisp like Clojure.