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: Sat, 8 Jan 2011 09:22:14 -0800 Message-ID: <0BC7B2E648C8499CAC13F1D3D3A7A72E@us.oracle.com> References: <6AF23E536D254FC88C35DA0BEC775C1A@us.oracle.com><7EB632A3268149CA89DA1D58C8046A01@us.oracle.com><9496EDBB00F3470E9417340D3CDBA5E1@us.oracle.com> <87tyhje666.fsf@gnu.org> 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 1294507469 6739 80.91.229.12 (8 Jan 2011 17:24:29 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 8 Jan 2011 17:24:29 +0000 (UTC) Cc: 7802@debbugs.gnu.org To: "'Jason Rumney'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jan 08 18:24:23 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 1PbcWd-0006gN-88 for geb-bug-gnu-emacs@m.gmane.org; Sat, 08 Jan 2011 18:24:23 +0100 Original-Received: from localhost ([127.0.0.1]:60255 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PbcWc-0005ed-Gx for geb-bug-gnu-emacs@m.gmane.org; Sat, 08 Jan 2011 12:24:22 -0500 Original-Received: from [140.186.70.92] (port=33702 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PbcWT-0005cQ-HK for bug-gnu-emacs@gnu.org; Sat, 08 Jan 2011 12:24:18 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PbcWH-0004gJ-9H for bug-gnu-emacs@gnu.org; Sat, 08 Jan 2011 12:24:13 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:51242) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PbcWH-0004g7-3u for bug-gnu-emacs@gnu.org; Sat, 08 Jan 2011 12:24:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1PbcOY-0006od-4K; Sat, 08 Jan 2011 12:16:02 -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 17:16:02 +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.129450692726159 (code B ref 7802); Sat, 08 Jan 2011 17:16:02 +0000 Original-Received: (at 7802) by debbugs.gnu.org; 8 Jan 2011 17:15:27 +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 1PbcNu-0006nl-4r for submit@debbugs.gnu.org; Sat, 08 Jan 2011 12:15:27 -0500 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PbcNs-0006na-4C for 7802@debbugs.gnu.org; Sat, 08 Jan 2011 12:15:20 -0500 Original-Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p08HMc89024316 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 8 Jan 2011 17:22:39 GMT Original-Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p08GuHln018857; Sat, 8 Jan 2011 17:22:37 GMT Original-Received: from abhmt001.oracle.com by acsmt355.oracle.com with ESMTP id 910182221294507336; Sat, 08 Jan 2011 09:22:16 -0800 Original-Received: from dradamslap1 (/10.159.216.42) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 08 Jan 2011 09:22:14 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87tyhje666.fsf@gnu.org> Thread-Index: AcuvTUqn3xUTjWVsQvKre08FFbRUWQABRRRg 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 12:16:02 -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:43212 Archived-At: > > 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? > > No. Windows does the same as Emacs, which is why we inherit this > behaviour. Emacs design is based on Windows behavior (shudder)? ;-) (No, I assume that you mean only that the Emacs implementation for Windows adapts to Windows limitations.) > > 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. > > The standard situation on Windows is rather more limited. There are no > double click bindings for mouse-2 or mouse-3 in most programs > or on the desktop, only for mouse-1. And the click event for mouse-1 > generally selects the item below the mouse pointer, which the double > click event then uses. Are you saying that a Windows program _cannot_ bind a double-click mouse-2 or mouse-3? Or that a Windows program can _only_ have double-click mouse-1 select the item under the mouse pointer? I don't think so, given the qualifiers you added. That Windows doesn't use double-click mouse-2 or mouse-3 events much by default is of course no argument for not letting Emacs do so. And even if Windows were by necessity "rather more limited", that wouldn't be an argument for limiting Emacs (in general) in this respect. I'm not familiar with this stuff, so I mentioned Windows just as a casual Windows user. My impression was (is) that it _can_ easily distinguish a single click from a double click, but I trust your knowledge about this. > > But why not just try to wait and see what the user action really is? > > How long do you propose to wait? Oh, I dunno - some reasonable defined and documented time period. ;-) How about variable `double-click-time' (or some small adjustment thereof, if that's not entirely appropriate)? Its two descriptions fit this well, AFAICT: "Maximum time between mouse clicks to make a double-click. Measured in milliseconds. The value nil means disable double-click recognition; t means double-clicks have no time limit and are detected by position only." [doc string] "The variable `double-click-time' specifies how much time can elapse between clicks and still allow them to be grouped as a multiple click. Its value is in units of milliseconds. If the value is `nil', double clicks are not detected at all. If the value is `t', then there is no time limit. The default is 500." [(emacs) Mouse Buttons] (Of course if the value of the option is `t' or `nil' then we would use a reasonable fallback time period for this. The point is that it is not heretical to consider having a defined timeout period to distinguish single-click from double-click.) And on Windows (at least) users can typically define a similar time period globally, in Control Panel > Mouse settings (e.g. tab Activities, in mine). That's one thing that gave me the impression that Windows did (does) correctly distinguish single-click from double-click. In the case of my mouse, at least, you double-click an animated graphic to test and see if the setting you are defining is adjusted to the value you want. (The exact interaction probably depends on which mouse you have.) I would think that that interaction alone indicates that Windows _can_ avoid just firing off some behavior as soon as it sees the first click. But maybe this preference-setting interaction is special - using the value you set as a timeout for the test, and the rest of Windows _cannot_ tell the difference between single-click and double-click adequately. (BTW, shouldn't Emacs on Windows pick up this user setting as the default value for `double-click-time'?) And FWIW we do use option `double-click-time' in the Lisp code here and there. E.g., both `foldout-mouse-swallow-events' and `org-mouse-show-context-menu' use it this way: (sit-for (/ double-click-time 1000.0)) See also option `viper-multiclick-timeout', which uses it with a fallback of 500ms. (XEmacs apparently has `mouse-track-multi-click-time' for a similar purpose to our `double-click-time'.)