bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Sat, 07 Jan 2012 20:59:53 +0200

> From: Stefan Monnier <address@hidden>
> Cc: Jason Rumney <address@hidden>,  address@hidden,  address@hidden,  
> address@hidden,  address@hidden
> 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?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]