[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [elpa] externals/exwm 0b8a373: Fix a `unread-command-events' issue f
From: |
Stefan Monnier |
Subject: |
Re: [elpa] externals/exwm 0b8a373: Fix a `unread-command-events' issue for Emacs 24 |
Date: |
Thu, 14 Jul 2016 21:48:11 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) |
> 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.
> 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
> timely.
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.
> Also there're related bugs with `unread-command-events' (bug#23980).
> Could you take a look?
I'll take a look,
Stefan