Unable to interrupt inferior process

[jabranham]

I haven't had time to look at this in much detail yet, but I'm not able to interrupt the inferior process with e.g. C-c C-c. The simplest way I could reproduce is with this R script:

cat("\n");Sys.sleep(100)

then C-c C-c to evaluate, switch to the inferior process and try to C-c C-c. I get a message about the text being read-only.

[mmaechler]

Yes, there are actually many situations where C-c C-c does not work in such cases. Good you're using such a nice repr.ex.
At least I can assure you this problem is not a recent one (and I'm wondering if we really haven't got an issue about this in the past).

NB there are cases where the R code itself is not easily interruptable, occasionally for a good reason, but mostly because the underlying C / Fortran code forgot to allow for interruptions; this is nicely covered in the "Writing R Extensions" manual (https://cran.r-project.org/doc/manuals/r-release/R-exts.html#Allowing-interrupts) -- but we are not talking about those cases here!

[vspinu]

I don't see this. This has something to do with the readonly prompts. I have those disabled in the inferior because I want to be able to edit the buffer freely.

[jabranham]

I submitted a patch upstream that fixes this issue. We'll see what they say and then maybe backport the change: https://lists.gnu.org/archive/html/bug-gnu-emacs/2019-01/msg00081.html

[prosoitos]

I have been in situations in which I could not interrupt an R process in iESS (which could otherwise be interrupted when run directly in R) often. In such cases, the only way out I have found was to call kill-buffer-and-window (well, I guess killing the buffer only would have been enough). I am very interested in any development or workaround here. Thank you!!

[jabranham]

@prosoitos Do you have comint-prompt-read-only set to t and Emacs complains that text is read only when you try to interrupt the R process?

[prosoitos]

I do have comint-prompt-read-only set to t indeed. I don't remember whether or not there was a message in the mini-buffer though. It is possible. All I can remember is that the little flipping bar in the mode-line indicating that the process was busy kept moving and that series of C-c (or C-g, Esc, C-d) had no effect and I had to eventually kill the buffer.

Should I set comint-prompt-read-only to nil?

[jabranham]

Should I set comint-prompt-read-only to nil?

That's personal preference, of course, but will probably fix this issue.

A "real" fix (so that comint-prompt-read-only doesn't result in this behavior) is currently being worked on.

[prosoitos]

OK. Thanks. I do prefer to have the prompt as read-only, so if a fix is in the future, I will stick to my setting. But it is useful to know that this is a workaround, if I run into the problem too frequently.

[jabranham]

This is fixed upstream and will make its way into Emacs 27.1. In the meantime, you can fix it for yourself locally by putting the following in your init file:

  (advice-add 'comint-skip-input :around
              (lambda (oldfun &rest r)
                "Set `inhibit-read-only' to t, then call OLDFUN."
                (let ((inhibit-read-only t))
                  (funcall oldfun))))