all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Jason Rumney <jasonr@gnu.org>
To: "Drew Adams" <drew.adams@oracle.com>
Cc: 7802@debbugs.gnu.org
Subject: bug#7802: bug #7802: 24.0.50; Extraneous `mouse-3' event when do `double-mouse-3'
Date: Sun, 09 Jan 2011 11:34:11 +0800	[thread overview]
Message-ID: <87oc7qeong.fsf@gnu.org> (raw)
In-Reply-To: <0BC7B2E648C8499CAC13F1D3D3A7A72E@us.oracle.com> (Drew Adams's message of "Sat, 8 Jan 2011 09:22:14 -0800")

"Drew Adams" <drew.adams@oracle.com> writes:

>> No. Windows does the same as Emacs, which is why we inherit this
>> behaviour.
>
> Emacs design is based on Windows behavior (shudder)?  ;-)

No. But the fact that Windows has the same design leads weight to the
fact that this is a valid design decision.

> Are you saying that a Windows program _cannot_ bind a double-click mouse-2 or
> mouse-3?

Yes. If they want to handle double clicks of mouse-2 and mouse-3, or
triple clicks of any mouse button then they need to handle it themselves
the same way that Emacs does.

>  Or that a Windows program can _only_ have double-click mouse-1 select
> the item under the mouse pointer?

No. I was saying that normally that is what mouse-1 does in programs
that handle double clicks, so the fact that a double click also produces
a click event is not normally percieved as a problem.

> And even if Windows were by necessity "rather more limited", that
> wouldn't be an argument for limiting Emacs (in general) in this
> respect.

It was not supposed to be. I was using this example merely to show that
Emacs is not unique in this design decision.

>> > 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]

500ms is already a perceptable delay. And some users with motor control
difficulties may set it much longer.  If we did this I have no doubt
that YOU would be complaining about the response time of mouse click
events.

> (BTW, shouldn't Emacs on Windows pick up this user setting as the
> default value for `double-click-time'?)

I don't know if this setting is exposed to programs, as the intention is
for Windows to use it internally when generating double click events.
If it is exposed, then yes it would be good to use for the initial value
of double-click-time.





  reply	other threads:[~2011-01-09  3:34 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
2011-01-09  3:34             ` Jason Rumney [this message]
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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87oc7qeong.fsf@gnu.org \
    --to=jasonr@gnu.org \
    --cc=7802@debbugs.gnu.org \
    --cc=drew.adams@oracle.com \
    /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.