RE: question about `sit-for' and `C-g'

[Herring, Davis]

> It seems that all I had to do was define a substitute for `sit-for' that does
> exactly the same thing but also binds `inhibit-quit' to t around the call to
> `read-event'.

Or you can just do that binding around your call to `sit-for'.

> I'm still interested in the questions I posed and learning more about this.

At top level, C-g is bound to `keyboard-quit'.  In the minibuffer, it's 
typically bound to `abort-recursive-edit' (since reading from the minibuffer is 
a special, unadvertised kind of recursive edit).  Much more important, though, 
is that while not in a command loop (e.g., during `sit-for'), `quit-char' is 
turned directly into a `quit' signal (not SIGQUIT; that's an unrelated Unix 
concept).  That signal unwinds the call stack until it hits a recursive editing 
level (which catches all exceptions) and prints "Quit".

>From a conceptual if not a C-implementation point of view, then, `read-char' 
>and so forth do not handle C-g in any special way.  That is to say, it does 
>what it always does, and aborts the currently running Lisp code.  As it is 
>global and standard, they do not document that behavior; see (elisp)Quitting.

> My next question is whether `sit-for' itself should do the same thing: bind
> `inhibit-quit' to t.

Surely not.  Aborting a command like yours in a normal minibuffer would then 
abort the whole minibuffer (because you'd get C-g in `unread-command-events' 
AND the `quit' signal).  And while it's easy to add a let-binding to get the 
behavior you want, you couldn't ever go back were it the default.

Davis