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.
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.
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.
> tpope is one of only a few driving forces over on the Vim side of Clojure
tpope is indeed one of the few, but I'd hate for people to dismiss https://github.com/guns for his work on vim-clojure-static, vim-clojure-highlight, etc. Both have done a great job on those projects, but also with engaging with the community.
And let's not forget Meikel Brandmeyer, met him once, lovely guy. But also spent a lot of time delivering VimClojure back in the day. (I'm glad I don't have to suffer nailgun any more!)
I think there's plenty enough willing people (I'm one - I've contributed 1 or 2 line snippets here and there). But the environment is actually pretty damn nice already. No complaints.
> TimL functions are actually VimL dictionaries (objects) containing a dictionary function (method) and a reference to the enclosing scope.
So calling TimL functions have overhead that calling VimL functions don't. I don't know if there are other performance quirks too, but I would not expect this to produce the most optimal VimL code.
That said, code that exists always performs better than code that was never written in the first place, so if this causes plugins to be written that otherwise would not, then that's a net win. It's also entirely possible that the performance concerns end up not being an issue.
Personally, I've never written a VimL plugin, and I've never had a reason to use Clojure, but now I'm tempted to try both.
Of course, I am in a rather unique position of being able to bang out well optimized VimL in my sleep, so paradoxically that biases me against my own creation.
But that's easy to optimize away, I imagine. I read this as a way for forming closures and it's easy to see during compilation if the closure is necessary.
Actually, it's not a case right now, but it is reasonable to expect to have TimL generate on average better VimL than handwritten, like many C compilers do with asm. I guess "make it work" is more important right now than "make it fast", but if it becomes used, I'm sure it will improve quickly on performance front.
I haven't given this a try yet, but I can expect that, if it works well, it will be worth even a modest performance hit.
The comment for send-line-to-tmux... I've felt that pain before.
This is the best sort of April 1 announcement - something ridiculously ironic and playful, yet incredibly useful long term. Thanks so much for creating this, along with all of your plugins.
Note that I said among the fastest, because VimL uses native integers which Lua doesn't have. LuaJIT does have them but their conversion rules are different so there has to be some shim code (https://github.com/neovim/neovim/issues/392). There's also many other VimL -> Lua incompatibilities that will incur some slowdown but it should be wicked fast still.
Of course, I expect that many people will start writing native lua plugins after a while, it is a far more pleasant language, after all.
Kudos tpope, this is freaking awesome!
