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

[David Kastrup]

Stefan Monnier <address@hidden> writes:

>> -               Down-clicks are eliminated.
>> +               Up/Down-clicks are eliminated.
>
> Actually, up-clicks (in the sens of *mouse* clicks) are not
> eliminated.

Well, they are at _this_ location.  *mouse* clicks have been converted
to click/drag at that point.

> I think it's be better to explain that we auto-eliminate both the
> "down-<foo>" and "up-<foo>" events such that, depending on which of the
> up or down part of an event is the important one, we use "down-<foo> and
> <foo>" or "<foo> and up-<foo>"

Well, it is not really comparable since down-xxx + up-xxx for the mouse
are combined into one xxx or drag-xxx event: in this case the
"eliminated" down-xxx event still has its timing and area data
integrated into the resulting event.

When discarding an up-xxx event, the corresponding xxx event has already
been delivered.  I've thought about _modifying_ the original xxx event
to add the up-xxx info, but in the case where you need it, you need
something to trigger the related action anyway, and if such event-fixup
needs to be done, it can be done by the separately bound up-xxx code
under user control rather than silently modifying an already processed
event.

So the xxx-down/xxx combination has to work differently from xxx/xxx-up.
But the point is that this difference is in the keyboard queue
_frontend_ (the one creating the Lisp event, whether natively or
synthetically).  The keyboard queue backend can ignore this difference.

-- 
David Kastrup