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

[Eli Zaretskii]

> Date: Sat, 07 Jan 2012 11:10:48 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: claudio.bley@gmail.com, lekktu@gmail.com, 9087@debbugs.gnu.org
> 
>  > 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?  If not, what can we do to
>  > make the throwing more "immediate"?
> 
> Could you shortly explain the possible consequences of applying this
> patch

1. The crash is avoided. ;-)
2. The Emacs reaction to input event under throw-on-input is delayed
   until Emacs actually tries to read input.

(It is possible that 2. is actually what needs to happen in this case;
I don't know because the exact effects of throw-on-input are not
documented anywhere I could find.)

> and why the crash doesn't happen in non-compiled code

To trigger the crash, immediate_quit should be non-zero, because only
then would signal_user_input do a QUIT.  immediate_quit is set
non-zero by `nth' only when we run byte code that calls it (see
bytecode.c around line 1007); the function Fnth, called by
non-compiled Lisp code, does not do that.

The choice of `nth' is just one possibility to trigger this; you can
do it in any code that calls some primitive which sets immediate_quit
non-zero.