From: "Drew Adams" <drew.adams@oracle.com>
To: "'Jason Rumney'" <jasonr@gnu.org>
Cc: 7802@debbugs.gnu.org
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 [thread overview]
Message-ID: <0BC7B2E648C8499CAC13F1D3D3A7A72E@us.oracle.com> (raw)
In-Reply-To: <87tyhje666.fsf@gnu.org>
> > 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'.)
next prev parent reply other threads:[~2011-01-08 17:22 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-07 19:11 bug#7802: 24.0.50; Extraneous `mouse-3' event when do `double-mouse-3' Drew Adams
2011-01-07 19:20 ` bug#7802: bug #7802: " Drew Adams
2011-01-07 19:38 ` Drew Adams
2011-01-08 5:03 ` Stefan Monnier
2011-01-08 6:36 ` Drew Adams
2011-01-08 16:01 ` Jason Rumney
2011-01-08 17:22 ` Drew Adams [this message]
2011-01-09 3:34 ` Jason Rumney
2011-01-09 14:18 ` Drew Adams
2011-01-13 5:35 ` Chong Yidong
2011-01-13 7:15 ` Drew Adams
2011-01-15 3:29 ` Chong Yidong
2011-08-08 18:45 ` Drew Adams
2011-08-08 20:52 ` Chong Yidong
2011-01-13 17:32 ` Stefan Monnier
2011-01-08 19:50 ` grischka
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0BC7B2E648C8499CAC13F1D3D3A7A72E@us.oracle.com \
--to=drew.adams@oracle.com \
--cc=7802@debbugs.gnu.org \
--cc=jasonr@gnu.org \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).