Emacs hangs when opening help (re-open #954)

[hendrikweisser]

I'm experiencing what seems to be the same issue as reported in #954. That has been closed as resolved, but I believe should be re-opened. There are two comments on the issue reporting that the problem persists: https://github.com/emacs-ess/ESS/issues/954#issuecomment-572740250 https://github.com/emacs-ess/ESS/issues/954#issuecomment-655499551

[jabranham]

Thanks. I know what the issue is, should be able to fix it next week. If it's bothering you until then you can disable adding links in help pages as a workaround. I think the variable is named something like ess-help-add-links

On Mon, Jul 13, 2020, 2:28 PM hendrikweisser notifications@github.com wrote:

I'm experiencing what seems to be the same issue as reported in #954 https://github.com/emacs-ess/ESS/issues/954. That has been closed as resolved, but I believe should be re-opened. There are two comments on the issue reporting that the problem persists:

954 (comment)

https://github.com/emacs-ess/ESS/issues/954#issuecomment-572740250

954 (comment)

https://github.com/emacs-ess/ESS/issues/954#issuecomment-655499551

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/emacs-ess/ESS/issues/1025, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC24ZCLJ2B4GSCHEJZHUYFLR3NG3NANCNFSM4OYXZX3Q .

[hendrikweisser]

@jabranham: That sounds great! I looked for a variable named ess-help-add-links or similar, but I only found a function (ess-r-help-add-links) and I don't know how I would disable that.

[jabranham]

Sorry, I thought there was a variable to control that behavior but apparently I was mistaken. Just redefine ess-r-help-add-links to return nil:

(defun ess-r-help-add-links () nil)

[jabranham]

Just pushed something that hopefully fixes this issue - please test it out and let me know if you still have this problem.

[hendrikweisser]

@jabranham: Took me a while to get around to testing it, but it appears that the problem is indeed solved (using ESS version 20200825.829 from Melpa). Thank you very much!

[r2evans]

Reopen?

ESS-20201208.1047, hanging again with ?data.table::CJ, same symptoms as before.

[r2evans]

FYI, using 20201221.1551 (on emacs-26.3), while it no longer crashes, it now doesn't open any help at all (first first time). Loosely demonstrated:

|----------------------------------------------------------------||------------------------------------------------------------------------------|
| > library(data.table)                                          ||                                                                              |
| > ?CJ                                                          ||   Retrieving RDS aliases...                                                  |
|                                                                ||   ess-command: Timeout during background ESS command ’.ess.getHelpAliases()’ |
|                                                                ||                                                                              |
| > ?ls                                                          ||   Retrieving RDS aliases...                                                  |
|                                                                ||   ess-command: Timeout during background ESS command ’.ess.getHelpAliases()’ |
|                                                                ||                                                                              |
| > ?ls                                                          ||   (success)                                                                  |
|----------------------------------------------------------------||------------------------------------------------------------------------------|
| 1 U(Unix)**-  *R:1*      All (28,2) (iESS [R:1]: run , ElDoc)  ||   2 U(Unix)%*-  *Messages* Bot (60,0) (Messages ,) [next-line]               |
|----------------------------------------------------------------||------------------------------------------------------------------------------|

I would love to know how you have your ESS configured so that ?anything takes less than this 1 second async timeout. I've lived with 5-10 seconds for a long time, accepting it as "normal".

[lionel-]

I think this sort of commands should run asynchronously instead of synchronously. The inferior would be "locked" while the async command is running. This way there would be no hang. This is related to the plan of sending code to the process via an async queue, though it could be implemented independently at first.

In the meantime I'll bump the timeout for this command to 10 seconds. Please let me know of any other commands which needs a larger timeout. We might also bump it globally to a more forgiving delay. I have resisted this because locking the Emacs UI feels like a bug to me.

I would love to know how you have your ESS configured so that ?anything takes less than this 1 second async timeout. I've lived with 5-10 seconds for a long time, accepting it as "normal".

On macOS the 1 second timeout seems to be sufficient. It may be a Windows-only thing, and could come from either the R side or the Emacs side. Relatedly I have found out that sending ESSR to a local process with ess-remotes takes up to 15-20 seconds even though it's only 60ish kb. These delays are mysterious to me. Maybe they are due to how Emacs performs or synchronises IPC at a low level?

[r2evans]

In general, I've found emacs on windows to be sub-optimal in many ways. Some (most?) of them are related to forking issues (magit, though awesome, takes several seconds minimum for every command that calls git ... which is just about everything). You may have hit it perfectly that it's a windows issue. (I'm using it out of necessity, not by request :-(

Having said that, I understand (and agree fully) that you don't want to lock up the emacs interface. 10 seconds seems a bit on the high side. Is it configurable? I don't see a customize variable to be able to override the default.

[lionel-]

The 10 seconds are just for this command, the default is still 1 second. I'll add a customisable variable for the default once we have a better overview of which commands need a longer timeout.

[r2evans]

The problem is in ess-r-mode.el, where it is calling names(formals(u)) where u is derived from the help docs. Are you against doing something like the following:

--- ess-r-mode.el.orig  2020-12-29 11:40:58.413250600 -0500
+++ ess-r-mode.el       2020-12-29 11:58:41.876353900 -0500
@@ -2361,7 +2361,7 @@
         (when usage-objects
           ;; Get arguments:
           (setq usage-objects
-                (mapcar (lambda (u) (cons u (ess-get-words-from-vector (concat "names(formals(" u "))\n"))))
+                (mapcar (lambda (u) (cons u (ess-get-words-from-vector (concat "try(names(formals('" u "')))\n"))))
                         usage-objects)))
         (nreverse usage-objects)))))

(Addition of try and single-quotes around the u.) It does not seem to affect ?ls (or ??), and it now works for ?data.table::CJ and ?CJ (with data.table loaded).

Thoughts? I can submit a PR if you'd like an easy-button here.

[lionel-]

I think we should replace the regexp parsing of the usage sections on the Emacs side by a parse on the R side. If we pass the usage items as unmodified strings to an ESSR function, we should be in a better position to figure out what sort of object we have and how to get formals. The error handling would be easier on the R side as well. Perhaps in the future we could also pass namespace information and get better scoping for these objects but that could come later.

If you'd like to take a stab at this that'd be great @r2evans!

[epruesse]

Seeing this with ?colData (from RangedSummarizedExperiment) - Emacs just hangs there, no CPU activity for either Emacs or R, no reaction to C-c C-c or C-g, very frustrating. It seems to recover after an hour or so, but that's not the kind of time I can just wait. Is there no way to make this function interruptible?

[mmaechler]

Is this with a current (development) version of ESS? If yes, it would be nice to have an example from a package that is available more widely, so more people could potentially reproduce (or not!) your problem ..