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>, Jason Rumney <jasonr <at> gnu.org>
Cc: claudio.bley <at> gmail.com, rudalics <at> gmx.at, 9087 <at> debbugs.gnu.org, lekktu <at> gmail.com
Subject: bug#9087: Crash reading from minibuffer with icomplete-mode
Date: Sat, 07 Jan 2012 10:31:48 +0200

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: rudalics <at> gmx.at,  claudio.bley <at> gmail.com,  lekktu <at> gmail.com,  9087 <at> debbugs.gnu.org
> Date: Fri, 06 Jan 2012 19:42:24 -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.  The only difference between
handling of throw-on-input and C-g on Windows is that the latter can
also interrupt prolonged system calls.  But throw-on-input is not
supposed to do that, right?  And we are not in a system call in this
case, we are just in a long calculation done by byte code.

Jason, could you please chime in?  signal_user_input was written by
you.  Doing a QUIT from a thread other than the Lisp evaluation thread
is clearly not TRT, I think, so it must be taken out.  The question
is: is there some way we can honor immediate_quit here, or should we
just ignore it?  TIA.

(Once again, why isn't throw-on-input documented?  With only a short
doc string lacking any details, I have no way of knowing what exactly
its contract is.)

Previous Next

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