Is somebody here using neovim+deoplete+clojure_async as a completion system? I’ve been running in some problems the are quite odd. When using fireplace, async-completion works, but as soon as I start typing gibberish it will not continue to complete regular stuff afterwards unless I either restart nvim or reconnect to the nrepl. Interestingly with acid.vim instead of fireplace it always works. (So seems to be an issue with the fireplace_cider_completion_manager ?) Omnicomplete (aka non-async) on the other hand also still works. Currently i have acid and fireplace → needed some tweaking, is kinda messy and acid alone is buggy for some integral features like look-up doc… Maybe one of you ran into the same issue 🙂

Hi, author here 🙂

That's really odd.

> reconnect to the nrepl. What do you mean by this?

Just typing :Connect in nvim

And thanks for your fast reply!

That's double unusual. That shouldn't have any effect on how async_clj_omni is behaving.

You could turn on the debug log and see what the series of events are, that might give some clues.

https://github.com/clojure-vim/async-clj-omni/blob/master/pythonx/async_clj_omni/cider.py#L70-L71 these lines in particular might be interesting.

Yeah I don’t think it is an issue with async_clj_omni as acid always works.

Uh that got quite big

Here is an example where acid works and fireplace does not:

2018-07-14 08:18:07,456 DEBUG    [86778] (deoplete.fireplace_cider_completion_manager) Gathering candidates
2018-07-14 08:18:07,464 DEBUG    [86780] (deoplete.child) merged_results: end
2018-07-14 08:18:07,464 DEBUG    [86778] (deoplete.fireplace_cider_completion_manager) cider gather been called 8464e06985014eaaa8132680f94a2e72
2018-07-14 08:18:07,464 DEBUG    [86778] (deoplete.fireplace_cider_completion_manager) cider_gather watching msgid
2018-07-14 08:18:07,464 DEBUG    [86780] (deoplete.child) main_loop: end
2018-07-14 08:18:07,473 DEBUG    [86779] (deoplete.acid_cider_completion_manager) cider gather been called 01962b9b1d7c4994b873a5b14ef709b8
2018-07-14 08:18:07,473 DEBUG    [86779] (deoplete.acid_cider_completion_manager) cider_gather watching msgid
2018-07-14 08:18:07,475 DEBUG    [86779] (deoplete.acid_cider_completion_manager) Received message for 
2018-07-14 08:18:07,475 DEBUG    [86779] (deoplete.acid_cider_completion_manager) {'completions': [{'arglists': ['[bindings & body]'], 'candidate': 'r/with-let', 'ns': 'reagent.core', 'type': 'macro'}], 'id': '01962b9b1d7c4994b873a5b14ef709b8', 'session': '0cf11277-9f9c-4f90-b317-99a5aa97586f', 'status': ['done']}
2018-07-14 08:18:07,475 DEBUG    [86781] (deoplete.child) merged_results: end
2018-07-14 08:18:07,475 DEBUG    [86779] (deoplete.acid_cider_completion_manager) finished waiting for completion to happen
2018-07-14 08:18:07,475 DEBUG    [86779] (deoplete.acid_cider_completion_manager) response truthy? True
...
...
2018-07-14 08:18:07,969 DEBUG    [86778] (deoplete.fireplace_cider_completion_manager) finished waiting for completion to happen
2018-07-14 08:18:07,969 DEBUG    [86778] (deoplete.fireplace_cider_completion_manager) response truthy? False

That False is quite interesting..

fireplace specifies an error handler where it removes the connection, so after an error it should clean up and try again.

But, maybe, hmm... https://github.com/clojure-vim/async-clj-omni/blob/master/pythonx/async_clj_omni/cider.py#L65-L66 Maybe it's not throwing a brokenpipeerror? But then what is it doing?

We're pretty much timing out on the connection here, maybe in that case we should always recycle the connection? I can't think of a healthy case where we get no response back. Except maybe speed.

I wonder if it is a speed problem...

No, why would failing a few completions cause speed issues later?

@david.bach21 does this happen if you only have fireplace installed?

But still, the connection shouldn't get locked up by this...

Yep just tried it with a minimal nvim config again and only deoplete, async_clj and vim-fireplace. Writing :Connect ... makes it work again. In order for it to break I need to type something which cannot be completed

like (mapr

Annoyingly, I can't reproduce.

Immediately after the r the completion stops and nothing shows up again even for correct stuff

So weird

probably worth checking, what cider-nrepl version do you use?

OS is probably relevant too, given that it's socket related. Maybe sockets operate slightly differently under linux than mac, for example.

I’m running mac and [cider/cider-nrepl "0.17.0"]

lein 2.8.1 if that matters

it shouldn't. I do run LInux, so that's one difference, but sockets are so similar I wouldn't expect htis.

you could try adding debugging to: - on_error in fireplace - pre-post nrepl.send() calls just to see where the hold up is.

After that you have to start adding debugging to the submodule to figure out what is blocked I suppose

Will do! Thanks a lot for your help 🙂 I’ll keep you posted

Okay so I’ve done some debugging and the on_error() in fireplace gets never called so the connection seems to be intact. The nrepl.send() calls also work as they just dispatch a send call via the watchable connection. I realized that the completion_callback() in cider.py is never called in the case when the completion stops. It seems that the connection somehow blocks or that cider_gather() watches for completion which never occurs in cases when it looks for gibberish but then not resets itself. I got it to work though by removing the first line in the following code: https://github.com/clojure-vim/async-clj-omni/blob/master/pythonx/async_clj_omni/fireplace.py#L35 and properly indenting the rest. So every time it gathers candidates it connects again to the nrepl via the url.

Speed wise it seems a tad slower then acid but I will do some more testing

That creates a new watcher for every completion. That means that if a message starts getting held up, this will fix it, at a cost to speed.

I'm really confused as to why messages are getting held up...