From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Let input queue deal gracefully with up-events Date: Thu, 29 Jan 2015 09:49:09 +0100 Message-ID: <87zj92nf96.fsf@fencepost.gnu.org> References: <1422451883-6530-1-git-send-email-dak@gnu.org> <874mrapkt9.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1422521776 13576 80.91.229.3 (29 Jan 2015 08:56:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 29 Jan 2015 08:56:16 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 29 09:56:15 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YGkta-0001lN-FP for ged-emacs-devel@m.gmane.org; Thu, 29 Jan 2015 09:56:14 +0100 Original-Received: from localhost ([::1]:58306 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YGktZ-0003rP-Op for ged-emacs-devel@m.gmane.org; Thu, 29 Jan 2015 03:56:13 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36746) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YGktW-0003r8-71 for emacs-devel@gnu.org; Thu, 29 Jan 2015 03:56:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YGktV-0002RM-2g for emacs-devel@gnu.org; Thu, 29 Jan 2015 03:56:10 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:50327) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YGktU-0002RI-VG for emacs-devel@gnu.org; Thu, 29 Jan 2015 03:56:08 -0500 Original-Received: from localhost ([127.0.0.1]:57502 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YGktT-0004pn-VO; Thu, 29 Jan 2015 03:56:08 -0500 Original-Received: by lola (Postfix, from userid 1000) id D09EADF2EF; Thu, 29 Jan 2015 09:49:09 +0100 (CET) In-Reply-To: (Stefan Monnier's message of "Wed, 28 Jan 2015 22:57:03 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:181967 Archived-At: Stefan Monnier 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