nrepl.el needs huge amounts of time to do autocompletion
jjpe opened this issue · comments
Using the latest nrepl.el and ac-nrepl packages from marmelade and with [org.clojure/tools.nrepl "0.2.2"] in my ~/.lein/profiles.clj, ac-nrepl will freeze whenever an autocomplete happens (triggered or automatic), freezing the nrepl/emacs UI along with it (without using extra CPU time I might add, and the rest of the system remains completely responsive).
The problem here is the 10+ secs it takes to do one autocomplete, not only making the feature defeat its own purpose, but effectively disabling proper typing in nrepl.el because of the automatic autocompletes while ac-nrepl is activated. This issue disappears on disabling ac-nrepl, prompting me to open an issue here as opposed to in nrepl.el.
The nrepl server is not on localhost, but on an android device I own, though that shouldn't be a problem as it never has been in the past.
In case it helps (TBH I don't really know if it's related), I found this entry in my Messages buffer when the latest AC was done:
Error in timer: (wrong-type-argument arrayp nil)
Did you load the file? I see similar behaviour when I have run M-x nrepl-jack-in but not M-x nrepl-load-current-buffer, it seems to be the cause of the (wrong-type-argument arrayp nil) message.
What happens if you enable debug-on-error? Extra information here would be a big help.
sw1nn: Can't load the file using either nrepl-load-file or nrepl-load-current-buffer (I assume the latter is a shorthand for the former, with both using the same code), they result in a FileNotFoundException.
This is not weird to me as the nrepl server host (my android device) has no way of finding the sources on my desktop without some special code telling it where to find it, but I can paste the stacktrace nonetheless if you'd like.
Steve: It turns out debug-on-error was already enabled, but now I'm wondering why as I get the feeling that is not supposed to be the case.
A couple of other things that may be useful:
- I can cancel the AC every time, but it takes C-g C-g C-g (yes three of 'em) to do it, and of course it doesn't prevent the next AC from happening.
- I use Prelude (https://github.com/bbatsov/prelude), I don't know if that has any bearing on the configuration of ac-nrepl.
I tried the same thing with an updated emacs config, based on the most Prelude version.
- Triggering ac now takes about 6 seconds, which is much less than than the 10+ from earlier, but unfortunately still not really usable.
- debug-on-error is still set to
tby default, though I still don't know why.
Sorry for not being on top of this right now; I'm a bit snowed under. I'll do my best to try to reproduce the issue locally, but if it's anything like #25, it might not be trivial to do so.
I figured it may be difficult to reproduce, that's why I'm trying to give as much useful debug info as I can. On that note, if there's anything else I can do please let me know.
EDIT: I just reached the conclusion that this delay only happens when the repl server is on my android device. Using the leiningen repl server, the issue does not present itself on my machine.
Going to go ahead and close this, since it doesn't seem to be either widespread or reproducible.