63
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 ...
56
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 ...
41
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 ...
13
You can roll your own predicate function that waits for 3 seconds and invariably returns non-nil (unless it is interrupted with C-g):
(setq confirm-kill-emacs
(lambda (&rest args)
(interactive)
(message "Quitting in 3 seconds. Press `C-g' to stop.")
(sleep-for 3)
t))
or a variant which will read any key:
(setq ...
11
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 ...
7
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.
(setq confirm-kill-emacs
(lambda (&rest _)
(message "Quit in 3 sec (`C-g' or other action cancels)")
(sit-for 3)))
6
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 ...
6
You could use hook calc-end-hook to hook delete-frame.
emacsclient -t --eval '(progn (add-hook (quote calc-end-hook) (lambda () (delete-frame))) (calc nil t))'
5
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.
5
you may define a separate command for C-x C-c like:
(defun keyboard-kill-emacs ()
(interactive)
(let ((confirm-kill-emacs 'yes-on-no-p)) ; temporarily enable the confirmation
(save-buffers-kill-emacs)))
(global-set-key (kbd "C-x C-c") 'keyboard-kill-emacs)
5
It also sometimes helps to abort-recursive-edit with C-].
4
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.
4
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 ...
4
@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 ...
4
The easiest, and I think best, way to get behavior similar to what you describe is to customize option help-window-select to non-nil (M-x customize-option help-window-select).
If you do that then when a *Help* window is displayed it is selected (gets the focus). So you can just hit q.
(This doesn't work for all help commands, but it works for most. It works ...
4
In most cases, an emacs instance runs for a very long time: what comes and goes is the buffer visiting a file. So instead of killing emacs as a whole, it is probably more useful to kill the buffer that is visiting the file.
You do that with kill-buffer (usually bound to C-x k): if the buffer is modified it will ask you whether you want to kill it anyway and ...
3
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-...
3
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?)
...
3
None of the other answers work for me. When my emacs hangs, I can only bring it back by killing and restarting it, but then after a while it hangs again. So there has to be a way to find out the reason.
One of the method that I used was to attach it to gdb. When emacs hangs, I executed the following command to attach gdb to Emacs:
sudo gdb attach 967
967 is ...
3
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 ()
(interactive)
(when (derived-mode-p 'mu4e-headers-mode)
(mu4e-mark-execute-all t))
)
How to debug ...
2
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 ...
2
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.
2
The short answer is yes, unfortunately. But see this question for hints on avoiding this in the future.
2
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,...
2
To reproduce exactly the same behavior in emacs -Q:
M-x toggle-debug-on-quit
M-x C-g
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.
2
The functions that bring up the *Help* window will sometimes move you to that window and sometimes not. That depends among other things on how many windows you had open before. In the common case where you only had one window it will stay there, since it's so easy to remove the other window with C-x 1 then. You get a message like
Type C-x 1 to delete the ...
2
The problem is that any commands you execute such as C-x C-c will be captured by the Emacs instance running EXWM.
The first thing to try - which did not work for OP - is to execute M-x exwm-input-grab-keyboard with the secondary Emacs window selected. This will set the window to char mode, and send the keys you type directly to that window. So C-x C-c will ...
2
The best solution is simply to hit C-c C-k (exwm-input-release-keyboard) which puts the X-window containing the inner emacs into char-mode. Then, when that window has focus, almost all keyboard input, including C-x C-c is passed to the inner emacs.
Hit s-r (exwm-reset) to get the window back to normal line-mode.
1
There are two parts to your question:
Kill all unmodified buffers.
Delete their frames.
For #2, do you really mean frames? In Emacs, a "frame" is a window-manager window, and an (Emacs) "window" is a pane of an Emacs frame (a frame shows one or more windows). Do you really want to delete a frame that might be showing an unmodified buffer in one of its ...
1
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:michael.albinus@gmail.com:/dir/to/file
Replace the account name with yours.
If ...
Only top voted, non community-wiki answers of a minimum length are eligible