I've run into some kind of O(n^2) or worse behavior when viewing very large (e.g. 128MB) files in Emacs and jumping to the end of the file. I think it may have to do with my coloring algorithm to color the text contextually. If I type control-g (keyboard-quit), the operation is not affected. I'd like some way to recover my emacs session without just killing it. I tried sending a SIGINT, but emacs just exited. Are there any signals I can send, or some other way (perhaps in a debugger) to force the whatever action is running to give up and return control to me?

  • I don't know of a way to make font locking interruptible, but you might find something of use in this Emacs Wiki page on speeding up font locking. Sep 11 '13 at 12:37
  • 5
    Did you try hitting escape 3 times ?
    – yPhil
    Sep 17 '13 at 8:39
  • Yes, I think your own font-lock code is probably at fault here. Examine your font-lock-keywords regexps carefully to try to find the problem.
    – Drew
    Sep 27 '13 at 6:37
  • 1
    EMACS: Eight Megabytes And Constantly Swapping :-)
    – user829755
    Nov 3 '13 at 14:40
  • 2
    Hitting escape three times does nothing for me.
    – WilliamKF
    Dec 17 '13 at 17:49

I doubt it's font lock mode. That probably only does sections near what's visible. It's probably copying data in memory.



These events are generated when the Emacs process receives the signals SIGUSR1 and SIGUSR2. They contain no additional data because signals do not carry additional information. They can be useful for debugging (see Error Debugging).

Source: GNU Emacs Lisp Reference Manual: Misc Events

I don't know what it would do (or what version of emacs you are running) but you could try a PROBABLY non-destructive signal (USR1 or USR2).

$ kill -USR1 pid

Or you could go to sleep and see if it recovers.

  • I wonder how busy (CPU and disk) your machine is. That might tell you a little about what it's doing. .. and you might be able to run another copy of emacs and "kill -USR1 pid" that new one to see what happens before you do the one you care about.
    – 9mjb
    Dec 11 '13 at 7:27
  • 3
    Wow, sending kill -USR2 to emacs-mac worked for me in a similar situation -- loaded a large file in js2-mode and started an isearch. USR2 quit the isearch and entered the debugger. Much better than killing the process!
    – William
    Jan 7 '15 at 1:06
  • I disagree with your doubts. The kill worked for me. It kicked me to the debugger and font-lock-default-fontify-region was where it was stuck.
    – Brian C.
    Feb 28 '17 at 15:19

I'm unaware of any signal handling that emacs does but you could use the Emacs Server by putting server-start in your ~/.emacs file so you can do RPC on your running instance of emacs.

Then when you want to kill emacs and write you can call from your shell emacsclient -e '(save-buffers-kill-emacs t)'.


Here was my answer to a similar question which may help: https://stackoverflow.com/a/47070702/3818556

So far the only way I found ever working is to send a SIGUSR2 signal to the busy emacs process using command line kill -- no matter if it's running as a server (with --daemon) or not. This will not force terminating the emacs process while being able to interrupt what it's doing. Let's try an example to break a sleep-for loop running on emacs server. (Yes, sleep-for can be break by C-g but this is just an example. It worked on some cases when emacs does not respond to keyboard commands.)

First, start emacs server then use emacsclient connect to it, enter M-: (sleep-for 120). Now go to another terminal and find the process ID of the server using command line: ps x|grep 'emacs.*--daemon'. Assuming the PID we found here is 12345. Now use the terminal to break it:

kill -USR2 12345

We should now see the sleep-for loop interrupted. On some cases I need to send this signal multiple times.

Also notice that SIGUSR1 does not work so SIGUSR2 is recommended, and this might only work on Emacs versions greater than v24. Hope this helps!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.