Fork me on GitHub
#vim
<
2018-07-14
>
David07:07:55

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 🙂

dominicm07:07:19

Hi, author here 🙂

dominicm07:07:57

That's really odd.

dominicm07:07:42

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

David07:07:47

Just typing :Connect in nvim

David07:07:18

And thanks for your fast reply!

dominicm07:07:14

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

dominicm07:07:34

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

David07:07:47

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

David07:07:04

Uh that got quite big

David07:07:47

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

dominicm07:07:25

That False is quite interesting..

dominicm07:07:29

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

dominicm07:07:39

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?

dominicm07:07:05

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.

dominicm07:07:10

I wonder if it is a speed problem...

dominicm07:07:56

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

dominicm07:07:12

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

dominicm08:07:32

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

David08:07:13

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

David08:07:45

like (mapr

dominicm08:07:31

Annoyingly, I can't reproduce.

David08:07:44

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

dominicm08:07:58

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

dominicm08:07:34

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

David08:07:09

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

David08:07:23

lein 2.8.1 if that matters

dominicm08:07:45

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

dominicm08:07:14

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

dominicm08:07:26

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

David08:07:48

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

David10:07:55

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.

David10:07:54

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

dominicm11:07:32

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.

dominicm11:07:51

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