timer handlers and ^G

[Ken Raeburn]

I found my Emacs session (built from a recent version on the 21.1
branch, but not precisely the release) hanging this morning.  Gnus
"demon" expiration of articles was running, the minibuffer says
"expiring articles in nnimap+imap.mekinok.com:fsck.rt.announce..." and
hitting ^G doesn't do anything.

(gdb) xbacktrace
0x81f8a00 "accept-process-output"
0x8793f50 "imap-wait-for-tag"
0x87d09e0 "imap-send-command-wait"
0x87947e4 "imap-mailbox-select-1"
0x85c3ff0 "imap-mailbox-select"
0x87e8f80 "nnimap-possibly-change-group"
0x87c1ad4 "nnimap-request-expire-articles"
0x852c434 "gnus-request-expire-articles"
0x84ebdfc "gnus-group-expire-articles-1"
0x8517820 "gnus-group-expire-articles"
0x850ed38 "gnus-group-expire-all-groups"
0x81f3b78 "byte-code"
0x84f4c38 "gnus-demon"
0x81f18e4 "apply"
0x81f3b78 "byte-code"
0x81ee614 "timer-event-handler"
(gdb) p Vinhibit_quit 
$8 = 405658444
(gdb) p Qt
$9 = 405658444
(gdb) 

Problem 1: The nnimap code doesn't seem to cope well when the
connection has gone away.  (I have no connection open to mekinok at
the moment, according to netstat.)  Also, the nnimap code probably
shouldn't even try to expire articles on a server for which
nnimap-authenticator is anonymous.  Those are issues for the Gnus
folks.

Problem 2: In timer.el, all event handlers are run with quits
disabled.  I can understand not wanting the handler list to get
corrupted, but not being able to interrupt the handler seems like a
poor idea.  I can experiment with, for example, pulling out the
function and callback arg with inhibit-quit set, and then actually
invoking the function after quitting is enabled again.  But does
anyone know of a reason why the event handler functions *should* be
invoked with quit inhibited?

Ken