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

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

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