[Top][All Lists]

[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.

reply via email to

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