>>>>> "GM" == Gerd Moellmann writes: GM> We had that on pretest-bug recently. I think it's not generally GM> a good idea, from the perspective of the user, to let C-g GM> interrupt functions run from a timer because (a) the user might GM> not be aware that such a function is running, and (b) because not GM> all such functions can cope with being interrupted. I suggested GM> to Simon Josefson, I believe, to explicitly bind inhibit-quit to GM> nil in Gnus if Gnus can cope with that. The problem with Gnus & al being able to hang Emacs is due to the timeouts it specifies on process operations not being honoured when they're run from a timer. (Normally `accept-process-output' on an asynchronous article fetch is the culprit, and there is a loop involving `select'.) This was reported before, but no-one could find anything wrong with process.c. If I remember correctly, it is reproducible by running from a timer a shell command which waits for a long time without producing output. Footnotes: If you happen to have `gnuserv' running, you can still use `gnudoit' to recover with `(top-level)' (?), as I recall. Also, the hang occurs under X. On a tty, if you C-g twice in this situation, Emacs offers to auto-save and then abort and dump core.