When C-g doesn't work, you can sometimes get control back with:
pkill -SIGUSR2 emacs
As @Archenoth points out, sending the SIGUSR2 signal to Emacs turns on debug-on-quit. This can be useful, but you'll want to turn it off again at some point (possibly immediately). To do this, call M-x toggle-debug-on-quit.
More information on using SIGUSR1 and SIGUSR2 ...
Before resorting to gdb, if you're using a Unix-y operating system, you can try sending SIGUSR2 to the Emacs process, like documented in the DEBUG file mentioned in the other answer.
$ kill -SIGUSR2 <emacs_pid_goes_here>
This will make Emacs attempt to break out of its current loop into the Lisp debugger.
Or use this one liner without typing emacs ...
If the freeze goes away when you hit C-g, then you can use the built-in debugger. Type M-x toggle-debug-on-quit before sending the message, hit C-g when it freezes, and inspect the *Backtrace* buffer that comes up.
If C-g doesn't help, then the freeze probably happens in the C code, and you'll need to use an external debugger such as gdb. Hit C-h C-d to ...
You can roll your own predicate function that waits for 3 seconds and invariably returns non-nil (unless it is interrupted with C-g):
(lambda (&rest args)
(message "Quitting in 3 seconds. Press `C-g' to stop.")
or a variant which will read any key:
One way would be to use ibuffer:
Open ibuffer (I have it bound to a key, but M-x ibuffer will work.)
Mark all modified buffers: * m
Toggle the marks, so that unmodified buffers are marked instead: t
Kill the marked buffers: D
For frames, you can use delete-other-frames (C-x 5 1).
If you do this often you may want to define your own command. Here's a ...
You can use sit-for instead of using sleep-for plus t.
And the function need not be a command (interactive).
sit-for returns t if it waited and nil if the user interrupted the wait.
(lambda (&rest _)
(message "Quit in 3 sec (`C-g' or other action cancels)")
You cannot quit the describe-key command. The reason is simple: it cannot know whether you changed your mind about requiring a description of a key or whether you want a description of the key C-g. So it assumes it's the latter, because otherwise it would be impossible to get a description of that key.
You will just have to live with the *Help* buffer being ...
See kill-emacs-query-functions, which lets you query yourself to confirm quitting, to avoid accidental quitting.
See desktop.el, which lets you save most of the state of your session when you quit, and restores it at the next session. See the Emacs manual, node Saving Emacs Sessions. See also savehist.el and bookmarks.
you may define a separate command for C-x C-c like:
(defun keyboard-kill-emacs ()
(let ((confirm-kill-emacs 'yes-on-no-p)) ; temporarily enable the confirmation
(global-set-key (kbd "C-x C-c") 'keyboard-kill-emacs)
@Harald answered your question.
But I would not say "unfortunately". This is by design. Buffer *scratch* is designed for what its name suggests and its initial contents describe: It is a scratchpad, for throwaway content.
If you use it for some other purpose then you are misusing it.
But of course you might want a scratchpad that is automatically backed ...
Little-known trick... You can send an interrupting debug signal to Emacs with kill/killall/pkill.
pkill -USR2 emacs
When sent to Emacs, the USR2 kill signal will interrupt whatever Emacs is doing and drop you to a debugger. From there, you can likely tell what is causing the hang from the stack trace.
It's possible to unconditionally enter the debugger by sending the value of debug-on-event (should be USR2 by default) as signal as documented in the Error Debugging section in the Emacs Lisp manual.
I found this rather useless to be honest since it just gave me a way to inspect a backtrace, not to unfreeze Emacs. YMMV obviously. As noted in the comments ...
When killing Emacs, there are several hooks that may end up being called -- including, but not limited to, kill-emacs-hook, kill-buffer-hook (when a buffer is killed), write-file-functions hook (if a buffer is saved). A user can inspect a hook by calling M-x describe-variable and the name of the hook. A user can run a hook by evaluating (run-hooks NAME-OF-...
My answer at https://stackoverflow.com/a/4485083/324105 might be of interest (even though this is almost the opposite to what you actually asked for).
With the custom my-desktop command, I only load my desktop file when I want to do that. Once loaded, I do automatically save it (but to my mind, if I loaded a desktop file, why wouldn't I want to save it?)
When you use the -Q switch, you are telling emacs to not process both your init file AND the site init file. I suspect this prevents emacs from detecting and setting a default coding system. When emacs then tries to save a file, such as the eshell history file, it doesn't know what coding system to use.
I can think of two ways to solve this. The most ...
I temporarily solved the problem by deleting the file history located in ~\.eshell\. It appears that the entries of the last sessions of eshell are saved in this file. This solution is not satisfying as the problem can again arise.
This appears to be some kind of bug related to the GTK graphical toolkit. Switching to the Lucid build reportedly avoids the problem. For more about the difference between those toolkits, see my answer to On Linux why should one choose Lucid over Gtk gui for emacs?.
If someone experiencing this problem could debug it and find out the reason why it happens,...
To reproduce exactly the same behavior in emacs -Q:
Looks like you have the debug-on-quit variable set to non-nil. Either directly or by toggle-debug-on-quit command or my menu Options->Enter Debugger on Quit.
What is the actual problem and what can I do about it?
The hash is only initialized in mu4e-headers-mode. Therefore, you should correct mu4e-execute-marks in the following way if you want to call it in kill-emacs-hook:
(defun mu4e-execute-marks ()
(when (derived-mode-p 'mu4e-headers-mode)
How to debug ...
Not exactly the answer you are expecting, but:
If you are running on GNU/Linux in a GNOME environment, you could try the upcoming Emacs 26.1. Tramp offers a new method there, gdrive, which allows you to edit the file remotely on the Google drive. Something like
C-x C-f /gdrive:firstname.lastname@example.org:/dir/to/file
Replace the account name with yours.
You may consider setting (setq confirm-kill-emacs 'yes-or-no-p) as described in
One convenient function to use as the value of confirm-kill-emacs is
the function yes-or-no-p. The default value of confirm-kill-emacs is
And if you only want this to apply in the GUI version of ...
However, I would like to recommend an easy way of using emacs more efficiently.
First, you create emacs server:
This makes emacs run as daemon(server mode), which means that you have one emacs server and you can have multiple clients.
Now when you open emacs(using emacsclient -t or emacsclient -c depending on console/GUI), you create ...
With the suggestions of @elethan and @Tobias I was able to generate this stack-trace:
Debugger entered--Lisp error: (wrong-type-argument listp "make -k ")
call-interactively(save-buffers-kill-terminal nil nil)
And track it down to ...
As it was mentioned, C-g does not move point by itself. You mentioned in a comment that the region you sets started before and ended after the current point position, hence you can not use the trick of keeping point where it is.
I think one way of dealing with this problem is to push mark at current position before marking the region. Then you can recover ...
C-g does not move the point, so there's no “original position” to restore. If you want the select-some-region function to preserve the point, write it in such a way that it does preserve the point. With the function in your question, you could invert the point and the mark.
(defun select-some-region ()