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

parvizfarnia · 2024-07-02T18:06:45Z

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:

Launche a R session via M-R
Then run Sys.sleep(10)
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.

The text was updated successfully, but these errors were encountered:

jacobkasper · 2024-07-03T10:07:00Z

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

parvizfarnia · 2024-07-03T10:42:15Z

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 · 2024-08-05T03:46:26Z

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 · 2024-08-31T08:46:23Z

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 · 2024-09-02T12:54:55Z

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 · 2025-02-05T19:54:37Z

Hi!

Another user here having the same issue.

The author of corfu/cape suggested doing this:

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.

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

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 · 2025-02-06T10:12:26Z

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 · 2025-02-06T15:38:59Z

Thank you so much @idhx.

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

Best.

idhx · 2025-02-06T18:07:17Z

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 #'co
8000
mpany-R-args #'company-R-objects #'company-R-library)))
	      ;; nice but breaks with completion of r objects
	      (corfu-popupinfo-mode -1))))

r2evans · 2025-02-10T17:16:50Z

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 · 2025-02-11T15:15:11Z

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 · 2025-02-27T18:35:19Z

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 · 2025-03-07T18:16:31Z

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 · 2025-03-07T19:09:08Z

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)?

parvizfarnia · 2025-03-25T11:21:38Z

I just performed a test with Linux Ubuntu 24.04.2, Emacs 30.1, and ess-20250110.1437, and I can confirm that C-c C-c works perfectly. Therefore, the problem is either related to Emacs on Windows or ESS on Windows (I am not familiar with other operating systems, as I use only these two). I am writing this as a follow-up.

r2evans · 2025-03-25T13:37:13Z

@parvizfarnia what test did you perform? Using the combination of httpgd and plumber from #1297 (comment):

macos 15.3.2, R-4.4.3, hangs every time
ubuntu 24.04, R-4.3.3, hangs every time
windows, R-4.2.3, DOES NOT HANG
windows, R-4.4.3, hangs every time

All of the above tests are on the R console, no IDE (neither RStudio nor emacs/ess). I vote to close this issue, this is an upstream issue.

parvizfarnia · 2025-03-25T14:56:44Z

Why voting to close the issue when it has not been solved? At least people who have encountered the same problem might be able to find more useful information here.

You asked about the test that I performed. It was a small Shiny application. With 3 files in the same directory:

app.R

library("tidyverse")
library("shiny")

source("ui.R")
source("server.R")

shinyApp(ui, server)

server.R

server <- function(input, output, session) {
    ## Creating a reactive expression
    dataset <- reactive ({
        get(input$dataset, "package:datasets")
    })
    
    output$summary <- renderPrint({
        summary(dataset())
    })
    
    output$table <- renderTable(dataset())
}

ui.R

ui <- fluidPage(
    selectInput(
        inputId = "dataset",
        label = "A test dataset",
        choices = ls("package:datasets")
    ),
  verbatimTextOutput("summary"),
  tableOutput("table")
)

So what I did was to open app.R in Emacs and then I selected the entire buffer and did C-c C-c to run the program. This launched R console in Emacs which was blocked while the browser was open. Once I closed Firefox, I came back and I did C-c C-c
to interrupt Shiny and that worked it rendered R console and I was able to continue working again in R console.

I performed a second test, much simpler than the first one. All I had to do was to put the following code in a file and run it:

library("tidyverse")

while (TRUE) {
    print("A message inside an infinite loop!")
}

Again by simply doing a C-c C-c I managed to interrupt the infinite loop and that rendered me the normal R console to continue my work.

r2evans · 2025-03-25T15:27:54Z

I think there are at least two possibilities:

The "hang" you were seeing in the initial post is the same that I was seeing with my reprex.

If this is the case, I can demonstrate that the reprex reproduces outside of emacs/ess, therefore it is upstream and not something ESS can/should address. Close the issue.
The "hang" we have both seen are different hangs.

Since my hang is not in emacs/ess, it's a distractor and should not be considered.

You said that on linux emacs/ess "C-c C-c works perfectly", you can no longer reproduce the hang. I just tried your code in emacs/ess on windows and on macos, and it does not hang. Unless you can find a combination of OS, IDE, R, and/or package version that does reproduce the bug, then close the issue.

I'm not trying to bully you into closing it. If you are confident that there is a combination that will still hang despite your code working on three OSes, then please add that info so that the devs have something to work on. My focus is to auto-reduce issues so that the devs have fewer issues to address.

parvizfarnia · 2025-03-25T16:01:25Z

If you are confident that there is a combination that will still hang despite your code working on three OSes

Maybe I didn't express myself correctly. I never said that it works on Windows:
#1297 (comment)

I just said that it worked on Linux Ubuntu
#1297 (comment)

That's why I said, there could be an OS specific problem (ESS or Emacs, I've not idea)

r2evans · 2025-03-25T16:18:17Z

Yes, and then in my comment:

I just tried your code in emacs/ess on windows and on macos, and it does not hang.

I've tried your Sys.sleep() loop and your shiny code on linux, macos, and windows, and your code does not hang R in any of the OS/R/package versions I tested. I'm guessing that either it was due to another interaction we aren't currently aware of, or its underlying bug was fixed unbeknownst to me.

r2evans · 2025-03-26T04:43:38Z

FYI, in case the dev(s) of httpgd have insight, nx10/httpgd#215

parvizfarnia mentioned this issue Jul 2, 2024

sometimes R process hangs up #1296

Open

r2evans mentioned this issue Mar 25, 2025

httpgd+plumber hangs R nx10/httpgd#215

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

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

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

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

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

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

Comments

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!