C-c C-c doesn not interrupt the process in Emacs 29-3 while using ESS

[parvizfarnia]

Hello everyone,

My environment:

Emacs version : 29.3
OS: Windows 11 (64 bits)
ESS version downloaded from MELPA: ess-20240516.811
R version: 4.4.1

According to the online documentation:
https://ess.r-project.org/Manual/ess.html#Other

4.8 Other commands provided by inferior-ESS
The following commands are also available in the process buffer:

Command: comint-interrupt-subjob

C-c C-c Sends a Control-C signal to the iESS process. This has the effect of aborting the current command. 

However, no matter how many times the user enters C-C C-c the current running job/process in R terminal within ESS is not interrupted. It is easy to reproduce:

1. Launche a R session via M-R
2. Then run Sys.sleep(10)
3. And right after that try to interrupt before the 10 seconds of Sys.sleep via C-c C-c and you will see that it is not possible.

Am I missing something with this new version of Emacs or is it a bug?

Thanks in advance.

[jacobkasper]

This is a different problem than I reported. I can cancel the Sys.sleep command with C-c C-c

[parvizfarnia]

How do you proceed? You just put the cursor in iESS buffer and then you do C-c C-c ? Because when I do so, I just see C-c C-c being printed in iESS without any effect (= interruption)

To be sure, I checked on several different machines, and each time there is the same problem.

[Yousuf28]

C-c C-c then Enter works for me.
If i hit C-c C-c, it get printed on console but nothing happen. If I hit enter after that it gets interrupted. I am using doomemacs on windows. Emacs version 29-3

[idhx]

I'm experiencing a similar issue. C-c C-c followed by enter does not work for me.

I use corfu for autocompletion and suspect this might be a duplicate of #1226 (see also #1267). I'm applying the temporary workaround suggested in those issue (disabling auto-completion by setting corfu-auto to nil) and will report on whether I still experience this problem. Clearly disabling auto-complete is not ideal, but it would at least be good to confirm whether this is the origin of the bug.

[idhx]

This is a quick follow up to confirm that, in my case, setting corfu-auto to nil resolves the issue. Could others (esp @jacobkasper since they could not use C-c C-c Enter, like me) confirm whether the same applies for them? If so, this and #1296 might be duplicates of #1226.

Note: A possibly better stopgap than disabling autocompletion with corfu would be to use cape wrappers as suggested by the author of corfu here. I don't have time to try this now, but will report again if I do.

[maikol-solis]

Hi!

Another user here having the same issue.

The author of corfu/cape suggested doing this:

1. Try Cape sanitizers in order to fix the broken Capf (cape-wrap-noninterruptible, cape-wrap-purify). Of course these are only a stop gap measures.
2. Try cape-company-to-capf and use the Company backend with Corfu if the native Capf backend doesn't work.
3. Disable Corfu in ESS buffers

Is there someone having a piece of config to work around the issue? This bug is a kind of annoying and I would like to see how others have handled it.

Thanks for your help.

Best.

[idhx]

I've been using the following.:

(advice-add 'ess-roxy-complete-tag :around  #'cape-wrap-noninterruptible)
(advice-add 'ess-filename-completion :around  #'cape-wrap-noninterruptible)
(advice-add 'ess-r-package-completion :around  #'cape-wrap-noninterruptible)
(advice-add 'ess-r-object-completion :around  #'cape-wrap-noninterruptible)

[maikol-solis]

Thank you so much @idhx.

Maybe these lines should be upstream for now, until there is a definitive fix.

Best.

[idhx]

Glad this helped.

Incidentally, coming back to this thread made me want to try the second option:

Try cape-company-to-capf and use the Company backend with Corfu if the native Capf backend doesn't work.

I wanted to try this because I was encountering very slow completion whenever I used a print() statement in an R session with even a low number of objects loaded, exactly as described in #1247. The conversation there suggested that switching to the company-R-* backends might help.

I've only just added the following lines to my config, but they seems to be working well so far. It's really nice to be able to get completions from ESS's company backends in corfu. The only annoyance is that corfu-popup-info mode does appear to play well with the company-R-objects backend, so I've disabled that for now.

;; required for ess company backends
(use-package company
  :demand t)

;; Use ESS's company backends (with cape) to avoid hanging on print(). See
;; https://github.com/emacs-ess/ESS/issues/1247
(add-hook 'ess-mode-hook
	  (lambda ()
	    (progn
	      (setq-local completion-at-point-functions
			  (mapcar #'cape-company-to-capf
				  (list #'company-R-args #'company-R-objects #'company-R-library)))
	      ;; nice but breaks with completion of r objects
	      (corfu-popupinfo-mode -1))))

[r2evans]

I get the same behavior (C-c C-c not interrupting the R process) without corfu installed. I do use company-mode, I'll try disabling that for a while and report back if it still occurs.

Edit after a day: Many R sessions with company-mode disabled, still no change.

[r2evans]

I can reliably reproduce the behavior using the httpgd package. While I know I've had this problem without httpgd being used, I suggest something it does is disrupting ESS somehow. Coroutines? Background later-like things?

(Incidentally, Sys.sleep(10) from the OP is still interruptible for me, always. That makes me wonder if these are different causes/issues with the same symptom? It would make sense to break this discussion into a separate issue. @parvizfarnia have you checked your .Rprofile, project files, and other setup to rule out any lead-in code that might mimic the httpgd+plumber thing I've found here?)

This reproduces reliably on both macos (sequoia 15.2, R-4.3.3, ess-version: [elpa: 20241127.1620]) and linux (ubuntu 24.04, R-4.3.2, ess-version: [elpa: 20240821.1952]).

I'm asking others to consider what is happening under the hood in that could contribute to the not-interruptibility.

This does NOT hang (so it's not just httpgd):

while (TRUE) { Sys.sleep(1); message(format(Sys.time())); }
# 2025-02-11 09:18:17
# 2025-02-11 09:18:18
# 2025-02-11 09:18:19
#   C-c C-c
httpgd::hgd()
# httpgd server running at:
#   http://127.0.0.1:60946/live?token=6qZHAhGb
dev.list()
# unigd 
#     2 
while (TRUE) { Sys.sleep(1); message(format(Sys.time())); }
# 2025-02-11 09:18:23
# 2025-02-11 09:18:24
#   C-c C-c
41+1
# [1] 42

Demoing with a very simple plumber interface, using a single endpoint:

#* @get /test
function(req, res, ...) { Sys.sleep(1); pi; }

Using that plumber.R file in a fresh R session, this does NOT hang:

plumber::plumb("plumber.R")$run(port=9999)
# Running plumber API at http://127.0.0.1:9999
# Running swagger Docs at http://127.0.0.1:9999/__docs__/
#   C-c C-c
41+1
# [1] 42

Same plumber.R file, fresh R session, this DOES hang, every time:

Sys.getpid()
# [1] 38659
httpgd::hgd()
# httpgd server running at:
#   http://127.0.0.1:60978/live?token=f5a6qLEH
dev.list()
# unigd 
#     2 
plumber::plumb("plumber.R")$run(port=9999)
# Running plumber API at http://127.0.0.1:9999
# Running swagger Docs at http://127.0.0.1:9999/__docs__/
#   C-c C-c
#   C-c C-c
#   C-c C-c
### `kill -HUP 38659`
# Process R:1 hangup: 1 at Tue Feb 11 09:21:24 2025

I don't have to actually call the /test endpoint to get the interface to hang. Even if I do, it is always responsive, before and after my C-c C-c attempts to interrupt the inferior process.

As for signals to interrupt/kill the R process: I used -HUP above, in some loops (not using httpgd, sorry I don't have a reliable reprex for this aspect) I'm able to kill -INT <pid> and it may return to R's > prompt without killing the process, but -INT does not work in the plumber/httpgd reprex. I can use -PIPE once, but not on subsequent attempts in this R process.

Sys.getpid()
# [1] 39524
httpgd::hgd()
plumber::plumb("plumber.R")$run(port=9999)
# httpgd server running at:
# http://127.0.0.1:61644/live?token=r9gDWJsv
# Running plumber API at http://127.0.0.1:9999
# Running swagger Docs at http://127.0.0.1:9999/__docs__/
#   C-c C-c
#   C-c C-c
### `kill -PIPE 39524`
# Error in execCallbacks(timeoutSecs, all, loop$id) : 
#   ignoring SIGPIPE signal
41+2
# [1] 43
plumber::plumb("plumber.R")$run(port=9999)
# Running plumber API at http://127.0.0.1:9999
# Running swagger Docs at http://127.0.0.1:9999/__docs__/
#   C-c C-c
#   C-c C-c
### `kill -PIPE 39524` ...
#   C-c C-c
#   C-c C-c
### `kill -HUP 39524`
# Process R:1 hangup: 1 at Tue Feb 11 10:01:20 2025

My guess is that the httpgd/unigd mechanism has something in a background loop of sorts, and perhaps so does ESS? Are they stepping on each other? How do I determine what background "things" are happening or supposed to happen in ESS?

I've not seen any of the ESS devs chime in yet on this. Is there anything you've seen in the interaction with corfu, company-mode, or side-effect using httpgd+plumber that helps hone in on an internal process loop in ESS?

[r2evans]

I can confirm still an issue in

GNU Emacs 30.1 (build 1, aarch64-apple-darwin21.6.0, NS appkit-2113.65 Version 12.7.6 (Build 21H1320)) of 2025-02-24
ess-version:  [elpa: 20250110.1437] (loaded from /Users/r2/.emacs.d/elpa/ess-20250110.1437/)

with company-mode disabled.

[parvizfarnia]

I created this issue on July 2024 and I can confirm that the problem still persists:

OS: Windows 11 (64 Bits)
Emacs: 30-1
ESS (installed via M-x package-install): ess-20250110.1437

It is impossible to interrupt any running R program via C-c C-c, each time the string "C-c C-c" is simply printed on the R* (inferior) instead of interrupting. Seeing that others have also encountered the same problem is rather reassuring that I'm not the only one. I need C-c C-c particularly when I work with Shiny and I frequently have to stop the application.

I saw also that disabling company-mode was suggested. But even doing that didn't solve the problem.

[r2evans]

I think the fact that it seems exacerbated by background (async, even) R operations is most likely the right direction to head towards. For instance, I am fairly confident many (all?) of the auto-completion modes (including company-mode) are using R in the background, which seems clearer to me when I have R busy on something and completion doesn't work until it's free :-). My example using httpgd::hgd() is also doing things during spare cycles when R is idle, another background operation.

Unfortunately, "async" is hard enough for many R programmers, and how it integrates with elisp is more still.

I am interested in putting a bountysource on this (and some other ESS open bugs). I know the devs time is often taken for granted, and I don't want to maintain that vision. The fact that no devs have chimed in recently on this (or any?) issue is concerning: not that they're ignoring us, but perhaps they feel under-appreciated, over-worked, or something else. I think finding help to maintain ESS is a difficult chore, one I don't envy. There really are very few options for non-GUI R work that I and many others do, I would really like to see ESS continue to get maintenance and updates.

What say you ESS devs (I'm not yet @-ing you by name), is a bountysource or similar a well-received step? I may be able to donate an under-used laptop, and if I can install macos on it perhaps that would be a helpful step for some mac-specific issues (not this one)?