bug#21313: 25.0.50; Strange errors from dbus-handle-event

[Tassilo Horn <tsdh@gnu.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> Looking at QUIT, the difference between my original code and the new
>> one is just when process_quit_flag() is called.  process_quit_flag()
>> always signals quit.  So with the new code, the signal is handled by
>> the right recipient.  Who consumed (and discarded) it before?
>
> process_quit_flag itself:
>
>   void
>   process_quit_flag (void)
>   {
>     Lisp_Object flag = Vquit_flag;
>     Vquit_flag = Qnil; <<<<<<<<<<<<<<<<<<<<<<<
>
> The gotcha here is that C-g is handled specially, i.e. not by
> process_quit_flag, during processing of user input.

Ok, I see.

> That special handling was bypassed because process_quit_flag attempted
> to process it too early, and reseted the flag afterwards, thus
> disabling that special processing.

What's a bit confusing is that it has been handled at least partially:
Quit was echoed but there was no "real" effect.  So I guess somewhere
the quit signal emitted by process_quit_flag() was caught by whatever
code does echo messages and then re-signalled, and the top-level handler
discarded it because Vquit_flag was nil.

The question is if Quit should have been echoed at all?  Well, it's good
for the user to see that emacs received it but then he'll wonder like me
why it has no effect.  So maybe it should have echoed "Quit [ignored]"
or something like that.

>> Well, I think I just remember that I want to bind Qinhibit_quit to Qt
>> whenever I need to call Lisp functions from C.
>
> In debugging code that isn't supposed to disrupt the control flow,
> yes, that's a good rule.  But if you write C code for "normal"
> processing, then no, don't inhibit quitting like that just because you
> call Lisp.

Yes, obviously.

Bye,
Tassilo