bug#7802: 24.0.50; Extraneous `mouse-3' event when do `double-mouse-3'

bug#7802: 24.0.50; Extraneous `mouse-3' event when do `double-mouse-3'

[Drew Adams]

emacs -Q
 
(global-set-key [mouse-3]
                (lambda () (interactive) (message "AAAAAAAAAAAA")))
(global-set-key [double-mouse-3] 
                (lambda () (interactive) (message "BBBBBBBBBBBBBB")))
 
Now just double-click `mouse-3'.  You see message "AAAAAAAAAAAA" in
*Messages*, as well as message "BBBBBBBBBBBBBB".
 
This is a no-no.  There is, or at least there should be, no single-click
event.  There should be only a double-click event.
 
The Elisp manual says (node `Repeat Events'):
"If a double-click event has no binding, the binding of the
corresponding ordinary click event is used to execute it."
 
Note the condition: "if a double-click event has no binding".  If there
is a double-click binding then I do not think the single-click binding
should be invoked.  Users should be able to have a double-click binding
be invoked without a single-click binding also being invoked.
 
---
 
[BTW, the rest of the sentence, after the condition, is not correct.  It
is grammatically correct, but it doesn't mean much, and it certainly
doesn't mean what we want.
 
The binding of the "ordinary click event" (which first of all should say
"single", not "ordinary", which is undefined) is a command.  It is not
correct to say that some command "is used to execute it".  Execute what?
How is a command used to execute something?]

In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600)
 of 2011-01-03 on 3249CTO
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.4) --no-opt --cflags
-Ic:/imagesupport/include'
 

bug#7802: bug #7802: 24.0.50; Extraneous `mouse-3' event when do `double-mouse-3'

[Drew Adams]

OK, I see now (and remember) that this is "by design".  Further in the same node
it says:

 "When the user performs a double click, Emacs generates first an
ordinary click event, and then a double-click event.  Therefore, you
must design the command binding of the double click event to assume
that the single-click command has already run.  It must produce the
desired results of a double click, starting from the results of a
single click.

   This is convenient, if the meaning of a double click somehow "builds
on" the meaning of a single click--which is recommended user interface
design practice for double clicks."

But I don't see this as a great design.  Though it might sometimes be
"convenient" it is in general impossible to work around.

If a `mouse-3' always appears before the `double-mouse-3' that corresponds to
_what the user actually did_, then the `mouse-3' will always be handled before
the command bound to `double-mouse-3' is invoked.  So in general that command
can do nothing to undo what the `mouse-3' command did.

"Therefore, you must design the command binding of the double click event..."
means nothing in the general case.  No matter how that command or its binding is
"designed", the command is invoked too late to do anything, in general, about
what the single-click command has already done.

This is not great, IMO.

bug#7802: bug #7802: 24.0.50; Extraneous `mouse-3' event when do `double-mouse-3'

[Drew Adams]

> `mouse-3' will always be handled before the command bound to
> `double-mouse-3' is invoked.  So in general that command
> can do nothing to undo what the `mouse-3' command did.

What's more, you cannot even design the single-click command so that it someow
detects the situation and turns itself into a no-op, to get out of the way.
There is of course no way for it to know whether the following event is a
double-click event.

> "Therefore, you must design the command binding of the double 
> click event..." means nothing in the general case.  No matter
> how that command or its binding is "designed", the command is
> invoked too late to do anything, in general, about
> what the single-click command has already done.

Likewise wrt designing the single-click command.  How could you fix
`mouse-save-then-kill', for instance, to not do anything if the following event
is `double-mouse-3'?

Exercise: Design a command for `double-mouse-3' that will not let
`mouse-save-then-kill' first do its thing when you (just) double-click.  You can
even rewrite `mouse-save-then-kill' if that will help.

E.g., have `double-mouse-3' bound to a command that pops up a menu.  Try having
it not also delete the region if you first use `double-mouse-1' `mouse-3' to
select text.

> This is not great, IMO.

Sounds to me like this "design" is just a side effect of the implementation.
The doc tries to make a virtue out of the necessity that results from the
implementation - by claiming "convenience".  What it really should say is "This
is a sorry state of affairs; apologies."

But I hope instead of a doc workaround that this bug can actually be fixed...

bug#7802: bug #7802: 24.0.50; Extraneous `mouse-3' event when do `double-mouse-3'

[Stefan Monnier]

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

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.


        Stefan

PS: Of course, the same holds for double-vs-triple clicks, tho it's
largely irrelevant.

bug#7802: bug #7802: 24.0.50; Extraneous `mouse-3' event when do `double-mouse-3'

[Drew Adams]

> > 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. ;-)

bug#7802: bug #7802: 24.0.50; Extraneous `mouse-3' event when do `double-mouse-3'

[Jason Rumney]

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

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

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

> But why not just try to wait and see what the user action really is?

How long do you propose to wait?

bug#7802: bug #7802: 24.0.50; Extraneous `mouse-3' event when do `double-mouse-3'

[Drew Adams]

> > 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'.)

bug#7802: bug #7802: 24.0.50; Extraneous `mouse-3' event when do `double-mouse-3'

[Jason Rumney]

"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.

bug#7802: bug #7802: 24.0.50; Extraneous `mouse-3' event when do `double-mouse-3'

[Drew Adams]

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

So they _can_ bind them.

> the same way that Emacs does.

So it's not even a design decision, but the only possibility?
The Emacs way is the only way? ;-)

> > How about variable `double-click-time'
> 
> 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.

Try and see.  In Emacs we can put such things under the control of the
individual user.  It should be possible to use both approaches, with a user
option deciding.  Once implemented it should be easy enough to conditionally
ignore the timeout and get the current behavior.

> > (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.

I know nothing about whether it is exposed, but a quick google shows it might
be.  I see, for example, references to functions GetDoubleClickTime and
SetDoubleClickTime.  (Hm, the Emacs name is also `double-click-time'...)

http://msdn.microsoft.com/en-us/library/ms646258(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/ms646263(v=vs.85).aspx

http://www.pinvoke.net/default.aspx/user32/getdoubleclicktime.html?diff=y
http://www.jasinskionline.com/windowsapi/ref/s/setdoubleclicktime.html

bug#7802: bug #7802: 24.0.50; Extraneous `mouse-3' event when do `double-mouse-3'

[Chong Yidong]

Jason Rumney <jasonr@gnu.org> writes:

>>  "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.

It's cleaner to let the calling Elisp code worry about this.  That is to
say, the caller can bind the first click to a command that starts up a
timer to execute the "single click" action after a short period, and
bind the double click to a command that cancels that timer.

I vaguely recall that we used to try to separate single clicks from
double-click, and the resulting user experience was rather poor.  So it
should not be the default, but rather anyone who cares about this issue
can do as described above.

bug#7802: bug #7802: 24.0.50; Extraneous `mouse-3' event when do `double-mouse-3'

[Drew Adams]

> It's cleaner to let the calling Elisp code worry about this.  
> That is to say, the caller can bind the first click to a command
> that starts up a timer to execute the "single click" action after
> a short period, and bind the double click to a command that
> cancels that timer.
> 
> I vaguely recall that we used to try to separate single clicks from
> double-click, and the resulting user experience was rather 
> poor.  So it should not be the default, but rather anyone who
> cares about this issue can do as described above.

Oh, sure, that's easy to say.  But not feasible in practice - might as well
rewrite everything, not to mention having user code implement the distinction of
single-click from double-click each time.

If you want to understand the context, it is simple.  The code is here:
http://www.emacswiki.org/emacs/download/mouse3.el

The case in question is explained in the Commentary's `Note:'.  It is the case
of setting `mouse3-second-click-default-command' to `mouse3-kill/delete-region'
and `mouse3-double-click-command' to `mouse3-region-popup-menu', that is,
opposite to their default values in the file.

You can also try the code to understand what is involved - very simple and
nothing else to load.  The default values do what I suggested in the 11/30
emacs-devel thread "Variable behavior for `mouse-3' second click at same spot"
(which evoked zero response).  That was a followup to the 11/05 thread
"`mouse-save-then-kill' changes" which also went nowhere.

What this bug is about is the opposite approach to the default behavior in file
mouse3.el: have a double-click open a menu and a second single-click in place do
what it does in emacs -Q (delete the region).

Doing what you suggest would mean redefining `mouse-save-then-kill' completely
(since the first click is then involved in implementing the timeout), and it
would take away any flexibility.  And this is just one example (use case) of the
general problem.

Are you sure about your "I vaguely recall"?  I am not aware that we ever, ever
separated the two like you say.  That's certainly not the case at least as far
back as Emacs 20.

Why not try it (implement a real single/double click distinction) and _see_ if
the delay is bothersome in practice, instead of presuming that it is?  As I
said:

d> Try and see.  In Emacs we can put such things under the control of the
d> individual user.  It should be possible to use both approaches, with a
d> user option deciding.  Once implemented it should be easy enough 
d> to conditionally ignore the timeout and get the current behavior.

You are both just assuming that the effect would be undesirable, with no
demonstration.  Why not let the user decide?

It seems to me that something _is not_ a single click if enough time has not
elapsed to distinguish it from a double-click.  That seems definitional, to me -
I don't see how anything else makes sense.  Otherwise, you never, ever know
whether the intention was a single-click.  There is then no such thing as a
single or double click.  Assuming that anytime the mouse gets clicked we want to
invoke the single-click action seems aberrant and perverse to me.  Microsoft
(apparently) notwithstanding.

bug#7802: bug #7802: 24.0.50; Extraneous `mouse-3' event when do `double-mouse-3'

[Chong Yidong]

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

>> I vaguely recall that we used to try to separate single clicks from
>> double-click, and the resulting user experience was rather poor.  So
>> it should not be the default, but rather anyone who cares about this
>> issue can do as described above.

> Are you sure about your "I vaguely recall"?  I am not aware that we ever, ever
> separated the two like you say.  That's certainly not the case at least as far
> back as Emacs 20.

I think that when mouse-1-click-follows-link was first introduced, the
implementation did pause to check for a double-click binding before
following the link.  That would have been for Emacs 22.

bug#7802: bug #7802: 24.0.50; Extraneous `mouse-3' event when do `double-mouse-3'

[Drew Adams]

> >> I vaguely recall that we used to try to separate single clicks from
> >> double-click, and the resulting user experience was rather 
> >> poor.  So it should not be the default, but rather anyone who cares 
> >> about this issue can do as described above.
> 
> > Are you sure about your "I vaguely recall"?  I am not aware 
> > that we ever, ever separated the two like you say.  That's certainly
> > not the case at least as far back as Emacs 20.
> 
> I think that when mouse-1-click-follows-link was first introduced, the
> implementation did pause to check for a double-click binding before
> following the link.  That would have been for Emacs 22.

I see no difference in this regard between Emacs 22 and 23, or for that matter,
between Emacs 23 and 24.

bug#7802: bug #7802: 24.0.50; Extraneous `mouse-3' event when do `double-mouse-3'

[Chong Yidong]

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

>> > Are you sure about your "I vaguely recall"?  I am not aware that we
>> > ever, ever separated the two like you say.  That's certainly not
>> > the case at least as far back as Emacs 20.
>>
>> I think that when mouse-1-click-follows-link was first introduced,
>> the implementation did pause to check for a double-click binding
>> before following the link.  That would have been for Emacs 22.
>
> I see no difference in this regard between Emacs 22 and 23, or for
> that matter, between Emacs 23 and 24.

This was during the Emacs 22 pretest.

bug#7802: bug #7802: 24.0.50; Extraneous `mouse-3' event when do `double-mouse-3'

[Stefan Monnier]

> It's cleaner to let the calling Elisp code worry about this.  That is to
> say, the caller can bind the first click to a command that starts up a
> timer to execute the "single click" action after a short period, and
> bind the double click to a command that cancels that timer.

Admittedly, this is pretty delicate to do right:
- if nothing happens during those 500ms, run the timer.  O, that's the
  easy case.
- if a second clicks comes in before those 500ms cancel the timer.
  First difficulty: where do you put the code that cancels the timer?
- if another event like a click on another mouse button, or a keyboard
  key comes in before the 500ms, we should be careful to run the click
  command immediately (i.e. neither let the timer finish,
  not just cancel it outright).  And don't wait for this second event to
  complete to a key-sequence bound to a command (i.e. run the click
  command as soon as a C-x comes in, for example).
- but if that second event is a mouse-movement, we should not do anything.

I think the best place to put such code is somewhere around
function-key-map.  Just like down-mouse-N can be dropped and
double-mouse-N can be demoted to just mouse-N, we could turn mouse-N
events that aren't bound to new single-mouse-N events.  I guess we could
do it with code along the lines of:

  [Check that there's no mouse-N binding, but there is a single-mouse-N
   binding in the active key maps]
  (let ((event
         (catch 'timeout
           (let ((timer
                  (run-with-timer 0.5 nil
                                  (lambda () (throw 'timeout 'timeout)))))
             (unwind-protect
                 (let (event)
                   (while (progn
                            (setq event (read-event))
                            (not (memq event '(mouse-movement))))) ; Any other?
                   event)
               (cancel timer))))))
    (cond
     ((eq event 'timeout) [single-mouse-N])
     ((eq event 'down-mouse-N)
      (push event unread-command-events)
      [])
     (t
      (push event unread-command-events)
      [single-mouse-N])))


-- Stefan

bug#7802: bug #7802: 24.0.50; Extraneous `mouse-3' event when do `double-mouse-3'

[grischka]

>> No. Windows does the same as Emacs, which is why we inherit this
>> behaviour.

No.  If the application does not set CS_DBLCLKS (which emacs doesn't),
Windows sends single clicks only always.

> 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.)
> 

Emacs limits Windows to behave like X in favor for its own
implementation which behaves like Windows.

--- grischka