GNU bug report logs -
#7802
24.0.50; Extraneous `mouse-3' event when do `double-mouse-3'
Previous Next
Full log
View this message in rfc822 format
> `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...
This bug report was last modified 13 years and 312 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.