GNU bug report logs - #9087
Crash reading from minibuffer with icomplete-mode

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: claudio.bley <at> gmail.com, rudalics <at> gmx.at, 9087 <at> debbugs.gnu.org, lekktu <at> gmail.com, jasonr <at> gnu.org
Subject: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Sat, 07 Jan 2012 20:59:53 +0200

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Jason Rumney <jasonr <at> gnu.org>,  rudalics <at> gmx.at,  claudio.bley <at> gmail.com,  lekktu <at> gmail.com,  9087 <at> debbugs.gnu.org
> 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?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.