Emacs crashes on displaying docstring about ac-nrepl

[daviesian]

In case it helps, on my Windows machine I sometimes get no docstring, or I get a partial one like this:

https://dl.dropbox.com/u/29044/nrepl_weirdness_1.PNG

Hope that helps narrow it down. It may be that this partial docstring is the case that crashes emacs on the mac in the report above.

Cheers,
Ian

[dchelimsky]

I posted some debugging information that is specific to emacs-live but might still be helpful: overtone/emacs-live#19 (comment)

[thmzlt]

I can confirm this. Once in a while autocomplete will completely freeze Emacs, requiring force quit.

I am running GNU Emacs 24.1.1 (x86_64-apple-darwin, NS apple-appkit-1038.36).

[purcell]

Somewhat frustratingly (for you guys more than me!), I cannot currently reproduce this at all with the latest nrepl.el and ac-nrepl.el. Neither @samaaron's scenario nor @dchelimsky's (in overtone/emacs-live#19) lead to errors for me; I get reasonable popups and completions. Granted, I'm using nrepl-jack-in to fire up the nrepl backend, rather than running lein2 repl in the background.

It is a known issue that completion does not work when the namespace of the current .clj file does not yet exist, but a minibuffer message to that effect is displayed by the nrepl completion function, for which the main ac-nrepl function is now a thin wrapper.

And when completing a symbol like clojure.set/, a ClassNotFoundException may get thrown by the backend; this is due to a problem with the core.complete lib currently bundled with nrepl.

I guess at this point I'm also wondering what auto-complete config you are all using; Is there an easy way I can fire up emacs-live and reproduce this?

FWIW, the relevant parts of my config are (more or less) the following:

(require 'auto-complete)
(require 'auto-complete-config)
(global-auto-complete-mode t)
(setq ac-auto-start nil)
(setq ac-dwim nil)

(add-to-list 'ac-modes 'clojure-mode)

(setq tab-always-indent 'complete)
(add-to-list 'completion-styles 'initials t)

;; hook AC into completion-at-point
(defun set-auto-complete-as-completion-at-point-function ()
  (setq completion-at-point-functions '(auto-complete)))
(add-hook 'auto-complete-mode-hook 'set-auto-complete-as-completion-at-point-function)

(add-hook 'nrepl-mode-hook 'ac-nrepl-setup)
(add-hook 'nrepl-interaction-mode-hook 'ac-nrepl-setup)
(eval-after-load "auto-complete"
  '(add-to-list 'ac-modes 'nrepl-mode))

(add-hook 'nrepl-mode-hook 'set-auto-complete-as-completion-at-point-function)
(add-hook 'nrepl-interaction-mode-hook 'set-auto-complete-as-completion-at-point-function)

[samaaron]

Hey Steve,

Yep, it should be easy to fire up emacs-live to reproduce this. Just temporarily move aside your current ~/.emacs.d directory, then run the following brogrammer script:

bash <(curl -fksSL https://raw.github.com/overtone/emacs-live/master/installer/install-emacs-live.sh)

(You can say no when it asks you if you want to install your own user pack)

[samaaron]

Also, the freeze behaviour that this has been reported happens much less frequently than the crashing behaviour for me.

[purcell]

Ah, see, the completion in Emacs Live is wired up completely differently to mine. There, TAB calls yas/expand, which then presumably delegates to AC. So perhaps there's a nasty interaction there.

These days I'm wary of binding TAB to anything other than indent-for-tab-command, because the new Emacs 24 machinery behind that command is excellent -- first it tries to indent the line using the mode's indentation function, and then if the indentation didn't change, completion is attempted using completion-at-point-functions.

I used to use smart-tab to achieve the same effect, but there were no end of niggly problems.The code I posted above shows how to nominate auto-complete as a completion-at-point function.

I think it's possible to just add a snippets source to AC, then let it be in control, but I'm not 100% sure because it's a long time since I tried yasnippet.

-Steve

[samaaron]

I'm not entirely convinced the issue is related to binding tab as the crash doesn't require hitting tab. It's just triggered.after AC automatically pops up on a timer trigger. However I'll temporarily remove the yas stuff and see if it modifies things.

[purcell]

Agreed -- yasnippet may be a red herring. And the automatic pop-up behaviour is another difference in our configs: note my (setq ac-auto-start nil) above.

[purcell]

To be fair, I couldn't provoke a crash with Emacs Live either, so my observations above may be entirely irrelevant. :-)

[daviesian]

This all seems to be caused by the nrepl-send-request-sync function (line 1169 of my nrepl.el). It works by making an async request to the nrepl server and then looping, waiting until the response is non-nil. Unfortunately the response seems to arrive in chunks, and the default implementation aborts as soon as it sees the first chunk, leaving the plist data structure incomplete. This seems to crash @samaaron's emacs, and cause mine to display incomplete docstrings.

I replaced the function by evaluating the following:

(defun nrepl-send-request-sync (request)
  "Send a request to the backend synchronously (discouraged).
The result is a plist with keys :value, :stderr and :stdout."
  (with-current-buffer "*nrepl-connection*"
    (setq nrepl-sync-response nil)
    (nrepl-send-request request (nrepl-sync-request-handler (current-buffer)))
    (while (or (null nrepl-sync-response)
               (null (plist-get nrepl-sync-response :done)))
      (accept-process-output nil 0.005))
    nrepl-sync-response))

which forces the loop to wait until the response has fully arrived before returning.

I suppose this is really an nrepl issue rather than ac-nrepl. The documentation for nrepl-send-request-sync does say that its use is discouraged, but in any case I guess it should at least work.

Hope that helps.

Cheers,
Ian

[purcell]

@iandavies1985 Well, I'm to blame for nrepl-send-request-sync in the first place, since I contributed it to nrepl in order for add-ons like ac-nrepl to work.

Thanks for tracking it down! No wonder it was tricky to reproduce. I'll test this out and get it patched in nrepl core, then post back here.

[dchelimsky]

@purcell am I correct that this morning's 0.1.4 release of nrepl.el does not include this patch or similar?

[dchelimsky]

@purcell actually I can see that it didn't: https://github.com/kingtim/nrepl.el/blob/b75c78fb492858c6e5de112084db37e8acd64dbf/nrepl.el#L1198-1199

Unfortunate timing :(

[purcell]

Yep, it missed the release.

This isn't a great time in nrepl's evolution to be using the stable packages, IMO. I personally use the Melpa packages.

[purcell]

I'll go ahead and close this issue now that it's basically fixed in nrepl master.

[samaaron]

Unfortunately, Emacs still seems to crash for me when attempting to display an auto-completed docstring...

[purcell]

@samaaron That sucks. I'm at a bit of a loss, since I can't reproduce it locally.

[samaaron]

I'm in the process of recompiling Emacs to see if I just happened to have a dodgy binary...

[purcell]

Try a vanilla build from emacsformacosx.com.

[samaaron]

I just did, and didn't observe any crashes :-) I'm now recompiling my non-gui Emacs to see if that fixes matters there. All weird though.

[samaaron]

Oooh, the recompile seems to be pretty stable too. Fingers crossed it stays that way!

[purcell]

That's good news!

[samaaron]

It is! Especially as I'm doing a big talk tomorrow and wouldn't want Emacs to crash on me live in front of an audience...

[purcell]

Yes, that would be frustrating. You can keep a special working Emacs for those special occasions. :-)

[samaaron]

Hahaha :-) Every occasion should be special then!