ac-nrepl appears to break nrepl-enable-on-existing-clojure-buffers about ac-nrepl HOT 14 CLOSED

Thank for the report, Matthew!

Hey @samaaron - any thoughts on this?

from ac-nrepl.

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

from ac-nrepl.

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?

from ac-nrepl.

Sorry, I should be asking @kencausey that, since he filed the original issue with nrepl.

from ac-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.

from ac-nrepl.

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.

from ac-nrepl.

Great, thanks - that was my guess too, since I couldn't reproduce the issue. :-)

from ac-nrepl.

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.

from ac-nrepl.

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?

from ac-nrepl.

@samaaron From my side, I haven't even any idea about what's going wrong. Though in 30459da I changed the position of the class cache function in the nrepl hook chain.

from ac-nrepl.

@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 :-)

from ac-nrepl.

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

from ac-nrepl.

@twashing what looks suspicious about that excerpt?

from ac-nrepl.

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

from ac-nrepl.