Subject: bug#9087: Crash reading from minibuffer with icomplete-mode

From: Eli Zaretskii <[email-masked]>
Date: Sat, 07 Jan 2012 20:59:53 +0200

> From: Stefan Monnier <[email-masked]>
> Cc: Jason Rumney <[email-masked]>,  [email-masked],  [email-masked],  [email-masked],  [email-masked]
> Date: Sat, 07 Jan 2012 13:21:39 -0500
> 
> >> > I can avoid the crash with the patch below.  But it defers the
> >> > throwing until Emacs is done whatever it was doing (in this case,
> >> > evaluating byte code).  Is this acceptable?
> >> Is a C-g also delayed in a similar way under w32?
> > Yes, it is, at least in this case.
> 
> Then it's perfectly OK to delay the throw-on-input.
> 
> > (Once again, why isn't throw-on-input documented?
> 
> It's largely an implementation detail of while-no-input, used for
> non-essential background computations (e.g. icomplete).

Is it (and while-no-input) supposed to stop prolonged Lisp
calculations without delay?  If so, how exactly does that work on X,
where (AFAIK) keyboard input is not interrupt-driven?