Fork me on GitHub

@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.


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


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!


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 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


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.


@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


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