5

In Emacs, sometimes I start a shell with ansi-term, and then from this shell I run IPython (another shell) that enters a long loop printing a long, long output.

When this happens, I often want to sendSIGINT to stop the script that IPython is running, but sometimes this takes way too long for IPython to capture Ctrl+C Ctrl+C (there are times when IPython never seems to listen to it). Interestingly, this does not seem to happen when I run it from a regular terminal.

Why is this the case? Is it an Emacs or IPython problem?

Amelio Vazquez-Reina
  • 91,494
  • 132
  • 359
  • 564
  • Are you pressing "C-c C-c"? – abo-abo Mar 03 '14 at 16:26
  • @abo-abo Yes - I tried pressing it one, multiple times etc. The key to remember is that sometimes it works, but sometimes it looks like Emacs or IPython get "too busy" printing a lot of output and don't listen (e.g. if I do C-c C-c **early enough** in the printing, IPython stops, otherwise it doesn't) – Amelio Vazquez-Reina Mar 03 '14 at 16:31
  • 3
    I see what you mean and I can reproduce it. But with "C-g C-g C-c C-c" I can stop it. – abo-abo Mar 03 '14 at 16:35
  • What does `C-g` do here? And why do you have to repeat it? – Amelio Vazquez-Reina Mar 03 '14 at 16:36
  • 1
    `C-g` calls `keyboard-quit`. It's a low-level thing in the main Emacs command loop that stops any hanging stuff and gives keyboard focus to you. I call it twice just to be sure, no harm in that:) – abo-abo Mar 03 '14 at 16:38
  • 3
    Actually, "C-g C-c C-c" should work as well. And it's easy to remember: "gcc":) – abo-abo Mar 03 '14 at 16:39
  • 3
    I can reproduce the problem by running `yes` in an `ansi-term` buffer, and I can't stop it without killing the buffer. I've encountered this problem before, and I never found a satisfactory way to fix it. – jpkotta Mar 03 '14 at 22:57
  • @jpkotta - Are you able to stop it with `C-g C-c C-c` ? – Josh Mar 03 '14 at 23:05
  • @Josh No. FYI, I'm using `emacs -q`. I guess I spoke a bit too soon. If I do something like `C-c C-c C-x k`, which seems to pause it, the `^C` finally goes through to the shell. It seems like it just can't keep up with the massive amount of output. Maybe we can use whatever is causing that pause to make `C-c C-c` more robust. – jpkotta Mar 03 '14 at 23:18
  • 1
    @jpkotta I don't understand why `C-c C-c C-x k` pauses the process for you. In my machine, `C-x k` is bound to `kill-buffer`, and if I kill the buffer, I kill the process. What do you have `C-x k` bound to? – Amelio Vazquez-Reina Mar 03 '14 at 23:38
  • Sounds like a `M-x report-emacs-bug` thing to me (if there's not an existing one). – phils Mar 04 '14 at 01:50
  • 1
    That said, if I run `emacs -Q`, `M-x ansi-term` with `bash`, run `yes` in the shell, and *immediately* hit `C-c C-c` and wait for a couple of seconds while the output already generated finishes being displayed, then the command *is* cancelled with no other fuss. It definitely seems that it's just a matter of the buffer "catching up" with the output already sent. – phils Mar 04 '14 at 01:55
  • Another experiment: in a regular (non-Emacs) terminal shell, run `n=0; while true; do n=$((n+1)); echo $n; done` and see how much output is generated before you can `^C` your way out of it (some thousands of lines in my case). For me, the amount of output that eventually comes through when doing the same thing in the Emacs term is not too dissimilar; it's just that it takes much longer for Emacs to process all that incoming data. But I feel that the actual interrupt *is* reaching the process at the right time. – phils Mar 04 '14 at 06:37
  • 3
    @phils `C-c q` (bound to `term-quit-subjob`, which sends a `QUIT` signal, i.e. `SIGQUIT`) works always **immediately** terminating the process (not the terminal/shell) regardless of how much output Emacs is processing and how late I wait before sending the signal. So I don't think the problem with `SIGINT` is because it takes Emacs a while to process the incoming data (in comparison to a regular terminal). – Amelio Vazquez-Reina Mar 04 '14 at 13:41
  • @user815423426 Like I said, I'm using `emacs -q`, so `C-x k` is bound to `kill-buffer`. However, it doesn't immediately kill the buffer, it prompts you (I `C-g` the prompt, so the buffer isn't killed). Once the prompt shows up, the `^C` goes through; it's faster than just waiting for the buffer to catch up (like 10 vs. 60 seconds). – jpkotta Mar 04 '14 at 17:07

0 Answers0