@markwoodhall I don't understand the question too well. I've not used devcards though. Could you share what you have/what you do? I might know a few things to help.

Sure, so at the moment, I have a :Figwheel function that will eval (do (use 'figwheel-sidecar.repl-api) (start-figwheel!)). As far as I understand this will start the first cljsbuild where :optimizations is :none or nil. If I’m working on something with devcards, I’d also like to start the devcards build too so I have :FigwheelStartBuild devcards that will eval (do (require '[figwheel-sidecar.repl-api]) (figwheel-sidecar.repl-api/start-autobuild “devcards”)).

And what are you trying to achieve exactly? To me - that looks pretty good. You've automated what would normally be manual.

Have any of you seen this : https://github.com/hkupty/acid.nvim

I hadn't. That's great.

Exactly something I've been thinking about.

@dominicm well, that was the goal, to save that manual step. I was just interested if that was a common way of doing it really, or if there was an alternative, better way.

I'm pretty sure he's implemented my autocompletion there.. 😛

@markwoodhall The only other thing I could really think of is if there was some way to enumerate possible builds which would be candidates for dev and auto-run those? Alternatively - :Figwheel could take optional parameters of builds to start

https://github.com/hkupty/acid.nvim/blob/master/rplugin/python3/deoplete/sources/acid.py#L1 Lol!

Yeah, that might be better actually. I guess it’s also worth double checking that there is no option to configure the builds to start in project.clj.

It appears the author, @ingvij, is here in slack!

@ingvij A small caution about https://github.com/cemerick/nrepl-python-client is https://github.com/cemerick/nrepl-python-client/pull/11 https://github.com/clojure-vim/nrepl-python-client The clojure-vim team have a fork here which contains the fix.

I'm going to make some improvements/changes to the watchable at some point too I think. It'll be more specific to nrepl bencode protocol, but will handle network failures better. Treating a network socket as a file seems to be a slightly optimistic abstraction in terms of errors.

Yes, now I remember. There's an edge case in my asyncwatchable branch (which isn't a blocker to merge, because it's minor and the rest of the improvements are so significant). If you kill the repl and then launch a new one on the same port, then the read should fail. Due to asyncwatchable, it just sits there forever. It doesn't crash and completions just stop iirc. When you kill neovim, it will sit there forever because it's waiting for the thread to die.

My plan is to update the watcher to use proper polling instead of a loop of reading over the port.

Might change some compatibility though.

@ingvij I'm happy to support acid in clj-async-omni. That would hugely reduce maintenance burden for you I hope. 🙂

Looking at your tweaks, there might actually be a bug in your implementation. It's totally possible with async runners with nrepl for responses to come out of order. To avoid this, all messages should have a unique message id to which you subscribe so you can await the response. It looks (at first glance) that your system uses a filtering queing mechanism of some kind - but the filtering is done on op, it should probably be done on message id instead.

Not sure if deoplete will get confused if you return ["xyz", "xBC"] as a completion for "xB" because of incorrect ordering.

I've learned a lot about nrepl clients since I wrote async-clj-omni. I should totally do something with that.

That's it https://github.com/clojure-vim/async-clj-omni has it's latest major release!

The whole thing uses crazy async voodoo to maintain only one connection to the nrepl. It's not perfect, there is an edge case in there to do with connections dying beneath it. I'll fix those upstream someday (tm). I've been using this as my daily driver for 2 months without any hiccups.

@juhoteperi I'm going to delete the asyncwatchable branch at some point, so if you update and find nothing is working. Master now has the new nrepl client in.

@dominicm gitmodules file seems to contain two nrepl clients

@juhoteperi https://github.com/clojure-vim/async-clj-omni/tree/master/rplugin/python3/deoplete/sources might be more to do with how the sync happens.

Strange that git works that way

You should probably remove the entry from gitmodules manually

Git rm should take care of that, but it might not work in all cases

Though maybe it doesn't cause problems

Updated to master and seems to be working after submodule init & update

Hey all, sorry for taking long to answer.. It's been a while since I don't log in here.

@juhoteperi I thought I did remove it manually :face_with_rolling_eyes:

It'd be great if async-clj-omni supported acid

Derp. I think I removed it and then added it again.

@juhoteperi Removed manually

@ingvij I'd absolutely love to get that in. No idea how stable your API is.

Not very much to be honest.. I assume it'd be ok after 0.1 is reached

https://github.com/hkupty/acid.nvim/blob/master/TODO.md

I still have to take care of some issues. I'll fix that bug you mentioned earlier and then I imagine it'd be stable enough

Sorry for copying your code that way, btw.. I just needed something to prove the concept of acid.nvim and completion was pretty simple to implement

It'd be great if you could help me with acid, since I'm just scratching the surface of how nrepl works

@dominicm just switched over to async-clj-omni, working nicely! 🤓

Which is the official nrepl-python-client version as of now?

What is acid? Fireplace replacement?

Seems to be alternative to async-clj-omni currently as both provide depoplete source

acid is a plugin I'm writting to provide asynchronous support for clojure development

It is intended to be an alternative to vim-fireplace

Okay, interesting

async-clj-omni is very much specialized, so probably I'll drop support to deoplete as soon as acid is more stable and leave code completion to async-clj-omni

currently, acid and async-clj-omni provide somewhat the same support for completion, but acid still requires you to (require '[]) manually the namespaces you want completion