ac-nrepl appears to break nrepl-enable-on-existing-clojure-buffers
mjwillson opened this issue · comments
There's some discussion about this issue here: clojure-emacs/cider#168
Where the issue is finally tracked down to some kind of interaction between the two hooks registered for nrepl-connected-hook.
When ac-nrepl's hook comes first and nrepl-connected-hook has the value: (ac-nrepl-refresh-class-cache nrepl-enable-on-existing-clojure-buffers), the second hook doesn't seem to get called (or at least doesn't have the desired effect).
If I manually reverse the order of the callbacks via (setq nrepl-connected-hook (reverse nrepl-connected-hook)) all works OK.
Not sure if this is ac-nrepl's or nrepl's fault, but suspect the former -- any ideas?
Cheers
Thank for the report, Matthew!
Hey @samaaron - any thoughts on this?
No bells immediately ring. I'm super busy tonight and tomorrow, but I can take a look at it on Friday if nobody beats me to it...
Okay, so I can't reproduce this problem. Admittedly, the ac-nrepl-refresh-class-cache function can take a while to complete (while displaying the message "Caching JVM class names..."), but then everything proceeds correctly, and nrepl-interaction-mode is enabled in existing clojure-mode buffers.
Now, given that you've tried setting debug-on-error and not seen tracebacks, then I don't really know what might be going on here. What's the value of nrepl-connected-hook before you reverse it?
Sorry, I should be asking @kencausey that, since he filed the original issue with nrepl.
Without reversing it nrepl-connected-hook contains '(ac-nrepl-refresh-class-cache nrepl-enable-on-existing-clojure-buffers). I'm still able to reproduce the problem which is the inability to use ctrl-x ctrl-e in a clojure buffer (no lisp sub-process error). The variable inferior-lisp-buffer is nil.
OK, so I hadn't in fact updated my emacs packages in a while. Perhaps @mjwillson is similarly out of date?
Once I had updated nrepl and ac-nrepl it works fine (in my quick testing) without need to reverse the hook variable. I believe this issue can be closed and considered fixed.
Great, thanks - that was my guess too, since I couldn't reproduce the issue. :-)
I'm using emacs live. When executing M-x nrepl-ritz-jack-in, my environment would hang on the call, after Caching JVM class names... was printed out. I tried updating nrepl and ac-nrepl (using M-x package-install), but that didn't fix the problem. I ended up directly editing ~/.emacs.d/packs/live/clojure-pack/lib/ac-nrepl/ac-nrepl.el, commenting out the call to (ac-nrepl-cache-all-classes). And that solved my problem.
I'm more than willing to go with a more elegant solution. But this gets me up and running now.
Hi there,
a more elegant solution would be appreciated. I haven't managed to get ritz working alongside Emacs Live - I tried briefly a couple of times with no success and didn't really put in the effort to get it to work. It would be nice though.
Do you have any thoughts as to why the class caching is the issue here?
@purcell I have no idea what's going wrong either!
However, I have noticed that the cache isn't updated across JVM reboots any more (unless the original *nrepl* buffer is manually killed). I still end up swimming in multiple *nrepl-n* buffers :-)
@purcell In ac-nrepl.el, my commented code now looks like this (see here).
@samaaron And I'm still an emacs novice. So it's hard for me to know what's causing the class caching issue. But when I look at the ac-nrepl-fetch-all-classes function (see here), this looks suspicious: (concat @complete.core/nested-classes @complete.core/top-level-classes).
@samaaron Oh right... just the fact that there could be recursive calls made to classes and/or their nested classes. For example, before I commented out that bit of code, my project.clj had a :resource-paths entry that included src/ and test/: :profiles {:dev {:resource-paths ["src/" "test/" "etc/resources/"].... And that definitely hung the nrepl-ritz-jack-in (but not nrepl-jack-in) after the Caching JVM class names... message. When I removed the src/ and test/ entries, the hang went away (although came back for other reasons). So again, this is just conjecture on my part. But it seems that the ac-nrepl-fetch-all-classes function hangs under some conditions. And it seems possible that concat'g top-level and nested classes can get stuck in some loop, based on a classpath (or some environment).