[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: read-event in batch mode
From: |
Michael Albinus |
Subject: |
Re: read-event in batch mode |
Date: |
Tue, 04 Feb 2014 12:54:08 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) |
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.