Re: [elpa] externals/exwm 0b8a373: Fix a `unread-command-events' issue for Emacs 24

[Chris Feng]

>> +(eval-and-compile
>> +  (if (< emacs-major-version 25)
>> +      (defsubst exwm-input--unread-event (event)
>> +        (setq unread-command-events
>> +              (append unread-command-events (list event))))
>> +    (defsubst exwm-input--unread-event (event)
>> +      (setq unread-command-events
>> +            (append unread-command-events `((t . ,event)))))))
>
> This ends up choosing the version of the code at the time it's compiled
> rather than at the time it's executed (since this is a defsubst and the
> version chosen at compile time will end up being inlined everywhere).
>
> I'd advise against using defsubst here (performance is probably of no
> importance compared to the time it will take to process the event).

My concern was that the function would get called very frequently (on
every key event in certain circumstances) so I made them inline.  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.

> and while I'm here, I wonder why you use `append` instead of `push`,
> i.e. why you add the event to the end rather than to the beginning of
> the queue.
>
> The content of the queue is "the event we haven't processed yet", so in
> order to do something akin to rerunning the current event, you usually
> want to put at the beginning of the queue.

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.

Also there're related bugs with `unread-command-events' (bug#23980).
Could you take a look?  I hope it's not too late to fix them for
emacs-25.

Chris