From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#7802: bug #7802: 24.0.50; Extraneous `mouse-3' event when do `double-mouse-3' Date: Fri, 7 Jan 2011 22:36:04 -0800 Message-ID: <9496EDBB00F3470E9417340D3CDBA5E1@us.oracle.com> References: <6AF23E536D254FC88C35DA0BEC775C1A@us.oracle.com><7EB632A3268149CA89DA1D58C8046A01@us.oracle.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1294469655 16803 80.91.229.12 (8 Jan 2011 06:54:15 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 8 Jan 2011 06:54:15 +0000 (UTC) Cc: 7802@debbugs.gnu.org To: "'Stefan Monnier'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jan 08 07:54:08 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PbSgi-0006ig-1X for geb-bug-gnu-emacs@m.gmane.org; Sat, 08 Jan 2011 07:54:08 +0100 Original-Received: from localhost ([127.0.0.1]:54840 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PbSgh-0002s5-Jc for geb-bug-gnu-emacs@m.gmane.org; Sat, 08 Jan 2011 01:54:07 -0500 Original-Received: from [140.186.70.92] (port=42891 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PbSga-0002rz-VO for bug-gnu-emacs@gnu.org; Sat, 08 Jan 2011 01:54:03 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PbSgZ-0005ab-L5 for bug-gnu-emacs@gnu.org; Sat, 08 Jan 2011 01:54:00 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:37043) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PbSgZ-0005aW-I6 for bug-gnu-emacs@gnu.org; Sat, 08 Jan 2011 01:53:59 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1PbSKL-0000rB-TE; Sat, 08 Jan 2011 01:31:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 08 Jan 2011 06:31:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 7802 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 7802-submit@debbugs.gnu.org id=B7802.12944682103233 (code B ref 7802); Sat, 08 Jan 2011 06:31:01 +0000 Original-Received: (at 7802) by debbugs.gnu.org; 8 Jan 2011 06:30:10 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PbSJW-0000q6-Jg for submit@debbugs.gnu.org; Sat, 08 Jan 2011 01:30:10 -0500 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PbSJU-0000pd-Cz for 7802@debbugs.gnu.org; Sat, 08 Jan 2011 01:30:09 -0500 Original-Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p086bPdK025500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 8 Jan 2011 06:37:26 GMT Original-Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p086bOaM022385; Sat, 8 Jan 2011 06:37:24 GMT Original-Received: from abhmt018.oracle.com by acsmt353.oracle.com with ESMTP id 941560121294468565; Fri, 07 Jan 2011 22:36:05 -0800 Original-Received: from dradamslap1 (/10.159.216.42) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 07 Jan 2011 22:36:05 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Acuu8XVj1y4a+PTjTLG68sAipvs1DgACqEYg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Sat, 08 Jan 2011 01:31:01 -0500 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:43208 Archived-At: > > Sounds to me like this "design" is just a side effect of > > the implementation. > > That might be the case. There is a "design" argument in favor of this > behavior, tho, which is that otherwise we'd have to wait after a click > before running its command, to check whether it was the first part of > a double-click or not. I'm no expert on these things, but isn't that what the system (whatever system is handling mouse events) needs to do anyway? Doesn't Windows, for instance, have to wait to see whether an event is a single-click, double-click, or triple-click? I can't see how it could be otherwise (logically). I can't imagine some action kicking in just as soon as the first click is detected, without waiting to see whether the _user_ action is actually a single click or is really a double click. > Of course, we could try and only perform this waiting in the > case where there is a double-click binding, thus minimizing such > undesirable delays, but it still might lead to undesirable delays > giving the impression the system is somewhat unresponsive. unresponsive...or just smart, correctly sensitive to what the user did. I suppose your proposed optimization might make sense, if it doesn't lead to any problems of its own. But why not just try to wait and see what the user action really is? How do we know that would make things seem unresponsive? Again, I cannot imagine that a system could short-circuit things the way Emacs apparently does and still be trustworthy. I repeat that I know nothing about how such things are handled usually, but what Emacs does just seems wrong (flawed) to me. Does it sound right to you? What am I missing? (Probably a lot.) > PS: Of course, the same holds for double-vs-triple clicks, tho it's > largely irrelevant. Triple-clicks are no doubt rarer, if that's what you mean. But I wouldn't want to have double-click confirm "Do you really want to vote for Ronald McDonald?" and have triple-click confirm "Do you really want to launch this missile and start WW3?" The way it is designed now nothing important can be allowed to be disambiguated by the click count, it seems. ;-)