Skip to content


Subversion checkout URL

You can clone with
Download ZIP


ac-nrepl appears to break nrepl-enable-on-existing-clojure-buffers #24

mjwillson opened this Issue · 14 comments

5 participants


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?



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.

@purcell purcell referenced this issue from a commit
@purcell purcell Add the class cache function to the end of nrepl-connected-hook
Whatever the cause of issue #24, it seems more correct to add this hook
function *after* `nrepl-enable-on-existing-clojure-buffers`.

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

@purcell purcell closed this
@kingtim kingtim referenced this issue in clojure-emacs/cider

C-c C-k compilation not working #123


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?


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


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


@twashing what looks suspicious about that excerpt?


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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.