Fork me on GitHub

Finally merged Acid.nvim support into async-clj-omni


Also, have a blog post on Vim hitting the JUXT blog tomorrow containing an overview of the tools in our ecosystem. Including the quieter projects, that will syndicate through Planet Clojure too.


@jebberjeb neovim-client didn't escape my mention.


glad to hear it — Happy to see increasing activity surrounding vim clojure tooling.


I'm like, a pent up frustrated bear of vim at work. Every time something goes wrong with Emacs, I'm all like "That's odd, in vim we just..." 😆


now, if we just hard org-mode 😉


Really think I want to revisit the idea of building a mega-pack for vim / setup guide for vim with all this stuff in & explained.


Someone waas porting org-mode to python. But then the org-mode syntax changed again.


I don't like org-mode tbh. Simply because it's not a "standard" it will never fix. Great for an OS, not great as a universal format.


Yeah, having a modern guide for vim/clojure would be useful. On the project I’m on right now, we have a few people using vim. Seems like I heard about it more and more these days in the Clojure world.


That’s true. Well, doesn’t have to be org-mode, just a lot of the functionality. I get most of what I need for doing a logbook w/ vim-outliner, but that’s just scratching the surface.

dominicm16:12:37 I believe that this uses the python library (or is one...) I used it for a while, it's okay.


I tried it a while back, but I can’t remember why I left it.


Maybe it has matured since then.


I only used it a while back. For interop with emacs users.


RE the modern guide for vim/clojure, my blog post isn't a tutorial, but definitely a "look on the horizon" of modern vim/clojure.


So for more investigative members of your team, it should let them know where to look & what everything does


I think they’d be interested in knowing that there’s a world beyond vanilla vim-fireplace (not to take anything away from vim-fireplace).


vim-fireplace is great. But it's essentially a "backbone" which other plugins should/are built on top of.


Acid / Neovim-client could be better backbones.


Exactly. My thought was always, put lisp into the hands of vim plugin authors (especially the ones who are also Clojure users) and good things will happen. Arguably there was support for mzscheme / racket, but it was shoddy. Also, projects like Hy.


Now, having implemented it, it’s not that simple. I think neovim-client needs to do more than simply wrap the neovim api to be a good plugin authoring tool. Obviously it needs to be faster (maybe cljs), but more than that. I think it should expose/wrap some well-used set of vim functionality (via vimscript?) as a set of Clojure functions. In other words, you’d have a function to split the screen, rather than having to call (vim-command “:split”). That type of thing.


Yeah. I think @ingvij actually released the result of starting to do that in Python. I will question whether or not we're getting into vital.vim territory there perhaps.

dominicm16:12:52 very popular, apparently it has some generators now, so that the user doesn't have to install vital.vim


Oh, actually, I may have slightly missed your point there. I think vital.vim is still relevant though.


vital.vim looks pretty great


The vim-jp community is pretty great. It's times like this that I'm glad that we have a lingua franca online (even if I slightly dislike that it's English)


ah, Shougo is there


I think acid.nvim is trying to fill a gap where we have no async nrepl communication on neovim/vim land.


Hopefully, we can have freeze-free development for clojure with neovim


I'd actually be happy to have a vim-clojure plugin of some kind, which implements all the "standard" features for fireplace or acid.nvim


@dominicm a subset of acid.vim?


@jebberjeb Not really. Basically it would just use fireplace/acid as a generic nREPL backend for sending "stuff" to, and implement the doc, goto source, etc. features on top


So that when super-cool-new-repl-client comes out, it would just write a backend for this (and optionally add some new features specific to itself)


It's probably not viable really, nor that useful. How many times will a new nrepl client get written (not many I hope!)


I suppose there's potential for a vim8 uprising of some kind, where some implements an nREPL client using pure vimscript and channels.


some sadist 🙂


> sadist So, a vim user?


Then again, Emacs has a built-in therapist. So maybe that says something about them too 😛


acid.nvim simple exposes the nrepl in a sane, async way.. For those implementing the plugins in python (sorry about that), you can create both commands and handlers to deal with nrepl. Some exemples included. For those who develop on other languages, acid.nvim exposes a handler that calls a vim function, so any vim fn (VimL or RPC) can be used.


A command is something that sends data to the nrepl and a handler is a function that gets called once the nrepl returns..


Anything can be implemented on top of those


Callbacks & Fun for Python, all is good.


Python seems like the most logical choice to me.