Re: read-event in batch mode

[Michael Albinus]

Eli Zaretskii <address@hidden> writes:

>> > The "keyboard buffer" is a misnomer: that's actually the Emacs event
>> > queue, where all kinds of events end up, and from which they are read
>> > and processed.  Why is it a good idea to have more than one event
>> > queue?
>> 
>> Because some events should be processed in a particular order and others
>> in a different order.  They correspond to different "threads" of
>> execution.  The "keyboard buffer" normally corresponds to events coming
>> from the user, so their relative ordering is very important and should
>> not be changed.
>> 
>> But D-Bus events or file-notification events may be triggered by
>> processing that's completely independent/asynchronous from the user's
>> actions, so they should be processed by Emacs without having to wait for
>> previous user-events to be processed.
>
> We already have process_special_events that does what you describe,
> just add more events to what it handles.

Yes, that should work. But we would need more rearrangement, because
process_special_events seems to be called only after
kbd_buffer_get_event has returned already.

During feature freeze, we shouldn't rearrange that code. For the time
being I have extended the test in kbd_buffer_get_event, in order to read
special events also when not linked with D-Bus. This should solve the
problem also for the w32 case, I believe.

Best regards, Michael.