[Top][All Lists]

[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 12:58:34 +0200

> Date: Sat, 07 Jan 2012 11:10:48 +0100
> From: martin rudalics <address@hidden>
> CC: address@hidden, address@hidden, address@hidden
>  > 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

reply via email to

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