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

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

>> > I think I found the problem: the call to Fformat eventually calls
>> > print_object, which calls QUIT, which resets quit-flag.
>> 
>> I've seen it now.  Well, that's not what I would have expected.
>
> You should expect any potentially prolonged operation to call QUIT
> somewhere in its loop.  That's standard Emacs coding practice, meant
> to make Emacs more responsive.

Ok, so QUIT; in C code basically means, here is a position where the
current lisp execution could be aborted.  If it weren't in
print_object(), then you couldn't for example abort printing a list with
gazillions of elements and emacs would get stuck while doing so.

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?

Well, I think I just remember that I want to bind Qinhibit_quit to Qt
whenever I need to call Lisp functions from C.

>> > So you need to change the beginning of read_char like this:
>> >
>> >   ptrdiff_t count = SPECPDL_INDEX ();
>> >   specbind (Qinhibit_quit, Qt);
>> >   AUTO_STRING (format, "%S");
>> >   printf ("record_char: %s\n", SSDATA (CALLN (Fformat, format, c)));
>> >   unbind_to (count, Qnil);
>> 
>> Yes, that works.  So that's the C version of (let ((inhibit-quit t))
>> ...).  So specbind creates a dynamic binding, and with unbind_to you
>> pop entries up to a given index again, right?
>
> Yes.  See Flet (modulo the clutter) for a definitive evidence.
>
> (Btw, unwind-protect is implemented using the same mechanism in C.)

Seen that, thanks!

Bye,
Tassilo