all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: David Kastrup <dak@gnu.org>
To: Stefan Monnier <monnier@IRO.UMontreal.CA>
Cc: emacs-devel@gnu.org
Subject: Re: [PATCH] Let input queue deal gracefully with up-events
Date: Thu, 29 Jan 2015 09:49:09 +0100	[thread overview]
Message-ID: <87zj92nf96.fsf@fencepost.gnu.org> (raw)
In-Reply-To: <jwvoapil041.fsf-monnier+emacs@gnu.org> (Stefan Monnier's message of "Wed, 28 Jan 2015 22:57:03 -0500")

Stefan Monnier <monnier@IRO.UMontreal.CA> 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	other threads:[~2015-01-29  8:49 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-28 13:31 [PATCH] Let input queue deal gracefully with up-events David Kastrup
2015-01-28 14:58 ` Alan Mackenzie
2015-01-28 15:19   ` [PATCH v1] " David Kastrup
2015-02-05 17:23     ` David Kastrup
2015-02-05 19:11       ` Stefan Monnier
2015-02-05 19:27         ` David Kastrup
2015-02-05 21:07           ` Ivan Shmakov
2015-02-05 21:42             ` David Kastrup
2015-02-05 19:17       ` Ivan Shmakov
2015-01-28 19:35 ` [PATCH] " Stefan Monnier
2015-01-28 19:50   ` David Kastrup
2015-01-28 22:14     ` Stefan Monnier
2015-01-28 22:55       ` David Kastrup
2015-01-28 22:19 ` Stefan Monnier
2015-01-28 23:06   ` David Kastrup
2015-01-29  3:57     ` Stefan Monnier
2015-01-29  8:49       ` David Kastrup [this message]
2015-01-29 15:00         ` Stefan Monnier
2015-01-29 15:14           ` David Kastrup

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=87zj92nf96.fsf@fencepost.gnu.org \
    --to=dak@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@IRO.UMontreal.CA \
    /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.