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

["Drew Adams" <drew.adams@oracle.com>]

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