[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [elpa] externals/exwm 0b8a373: Fix a `unread-command-events' issue f
Re: [elpa] externals/exwm 0b8a373: Fix a `unread-command-events' issue for Emacs 24
Fri, 15 Jul 2016 10:22:37 +0800
>> My concern was that the function would get called very frequently (on
>> every key event in certain circumstances) so I made them inline.
> I don't think "every key event" (human scale) can be "very frequently"
> at the computer's scale. And in any case, the time to process the event
> later on will completely dwarf this.
>> As for your the problem you pointed out, my understanding is that
>> bytecodes for Emacs 24 and 25 are largely not compatible, at least for
>> this package which heavily relies on EIEIO. So even if we can choose
>> between the two functions at run time the compiled code still won't
>> run correctly.
> Oh, indeed if it uses EIEIO it's quite possible that recompilation will
> be needed anyway.
Yes, performance is technically not an issue here. But considering
that recompilation is always required, there's no need to change the
>> The events are received directly from X server (rather than Emacs) in
>> chronological order so I think it makes sense to append them to
>> `unread-command-events', in case previous events added not processed
> Say you have (X Y Z) in unread-command-events, and Emacs comes takes
> X out and processes it. If during processing you push the new event
> A at the end, that means it'll be processed in a different order than if
> Y and Z had been received a bit later.
> The right choice depends on the nature of the event you're pushing (A)
> and its relationship to the current event (X), so it has to be decided
> on a case-by-case basis according to the specific details.
> So maybe that's indeed the behavior you want (and I don't know nearly
> enough about the events you're manipulating to be able to tell), but
> usually in my experience you want to push to the front.
The key events are generated by the user and are received through a
subprocess in a non-preemptive way, so they're always processed in a
first-come, first-served fashion. `unread-command-events' is used as
a FIFO here.
>> Also there're related bugs with `unread-command-events' (bug#23980).
>> Could you take a look?
> I'll take a look,