[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Let input queue deal gracefully with up-events

From: David Kastrup
Subject: Re: [PATCH] Let input queue deal gracefully with up-events
Date: Thu, 29 Jan 2015 09:49:09 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Stefan Monnier <address@hidden> writes:

>> Well, it is not really comparable since down-xxx + up-xxx for the mouse
>> are combined into one xxx or drag-xxx event.
> That's one way to look at it.  If you look at it w.r.t XEmacs, where
> they have `button1' and `button1up' (IIRC), I prefer to consider that
> our `mouse-1' is an up event (and we simply define the click as
> happening on the up event).

Whether _you_ prefer to look at it that way does not change how Emacs'
internals look at it.

> The point here is just that the way the comment is written makes it
> sound like we'd throw away all events (both up and down), whereas we
> only throw away the "companion event" (either the up or the down one,
> depending on the specific kind of event).

I don't think it helps anybody if the code comments live in a different
universe than the code.

Emacs basically has two layers in the event code.  One layer deals with
events in C structures.  Where the C structures are converted into Lisp,
the basic up/click/drag machinery is implemented.  It is here that the
"up" modifier for mouse events disappears.  But that's before even
entering any user-visible data structures.  At the Lisp level (barring
Lisp-accessible semi-internals like the modifier-cache), the "up-"
modifier does not currently exist consistently (usually the tables have
it and the code doesn't).

Now for the Midi stuff (which should end up in Emacs some day),
implementing something like a "off-" or "release-" modifier does not
seem to make a lot of sense when the C layer already has symmetric
up/down, the Lisp layer has a half-implemented "up-", and the semantics
are quite similar to the mouse "down-".

I digress.  What I am getting up is that the Lisp layer of the event
code (namely where things are taken out of the Lisp event queues again
and read and/or looked up in keymaps and executed) does not know
anything about the origins of click/drag events and any prospective
relations to up-events in the C code.  And it does not _need_ to know
either.  That's stuff that happened before things went _into_ the queue.

This is basically the level where keymaps are consulted, where macro
recording and replay happens, and where synthetic events like from
xt-mouse.el gets inserted.

And at this level, there is _no_ relation between up events and
click/drag.  Comments suggesting otherwise will not help with
understanding the code.

David Kastrup

reply via email to

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