Emacs has code to deal with C-g being entered while a quit is already in progress, meant to suspend emacs and drop the user to the superior shell or debugger (see section 59.7 Emergency Escape of the emacs info). This is done if emacs believes it's a good idea, which criteria includes "running in tty mode". Unfortunately this was never updated to work correctly with the multi-tty patch. As a result the following can happen:
1) Start up an "emacs -Q -nw" (tty) instance and M-x server-start RET.
2) From another shell open a tty /or/ X frame to the same emacs.
3) In the second frame eval this and immediately hit C-g while the sleep-for is running:
(let ((inhibit-quit t)
(quit-flag t))
(sleep-for 10))
4) The second frame becomes unresponsive because the first (main) frame has suspended itself and dropped back to the invoking shell.
Note that that elisp snippet is a bit extreme - in fact this behavior can be triggered in much more innocuous ways, such as interrupting a *compilation* at an inopportune moment. But I don't have a simple repro recipe like the above for the more mundane ways this can trigger.
The relevant hint is in keyboard.c:handle_interrupt() which contains:
/* XXX This code needs to be revised for multi-tty support. */
if (!NILP (Vquit_flag)
I work around this in my personal builds by adding an "&& 0" to the end of the if line above, which disables the feature described by 59.7. An alternative workaround is to not use tty frames, or start up in a tty frame (say inside a GNU screen session), then start at least one X frame, and kill the original tty frame, which still allows one to have a persistent emacs server running that can be robust to the death of an X server (as long as it is displaying a frame on at least one other X server).
This bug is very easy to tickle accidentally; every user I've converted to multi-tty usage patterns that uses any tty frames (either inside a screen session for persistence or over ssh connections for speed) has run afoul of this at some point. As things stand I believe the feature does more harm than good. Since 23.1 will be the first release of emacs to contain the multi-tty functionality (advertised in NEWS as "Improved X Window System support") I believe it should be fixed before release. This will require either declaring 59.7 obsolete (intentionally removing the capability) or the attention of someone familiar with the workings of the tty code to resolve the XXX in the code.
FWIW I remember this happening with multi-tty years ago and repros in HEAD builds from 20080810, 20080702, and 20070829. Also, I believe that resolving this correctly should resolve Dan Nicolaescu's issue reported in emacs-devel email titled '"Auto-save? (y or n)" question when doing C-z' with Message-ID: <
address@hidden>.
Cheers,
-a