From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Chris Feng <chris.w.feng@gmail.com>
Cc: emacs-devel <emacs-devel@gnu.org>
Subject: Re: [elpa] externals/exwm 0b8a373: Fix a `unread-command-events' issue for Emacs 24
Date: Thu, 14 Jul 2016 21:48:11 -0400 [thread overview]
Message-ID: <jwvr3avptib.fsf-monnier+emacsdiffs@gnu.org> (raw)
In-Reply-To: <CAP4=87E7-MUahJ8fzUnmEp2ZKqgzdDvnMt4-yjy6s5V58mSreg@mail.gmail.com> (Chris Feng's message of "Fri, 15 Jul 2016 09:03:23 +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.
> 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
next prev parent reply other threads:[~2016-07-15 1:48 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20160715001351.14660.27588@vcs.savannah.gnu.org>
[not found] ` <20160715001351.9FD2C22014B@vcs.savannah.gnu.org>
2016-07-15 0:31 ` [elpa] externals/exwm 0b8a373: Fix a `unread-command-events' issue for Emacs 24 Stefan Monnier
2016-07-15 1:03 ` Chris Feng
2016-07-15 1:48 ` Stefan Monnier [this message]
2016-07-15 2:22 ` Chris Feng
2016-07-15 13:24 ` Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvr3avptib.fsf-monnier+emacsdiffs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=chris.w.feng@gmail.com \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.