bug#14793: 23.4; Cannot bind a function to a sequence of two mouse keys

[Eli Zaretskii <eliz@gnu.org>]

> From: Alex <agrambot@gmail.com>
> Cc: 14793@debbugs.gnu.org,  npostavs@users.sourceforge.net,  regularclockwork@gmail.com
> Date: Wed, 04 Oct 2017 21:58:41 -0600
> 
> There are a couple issues that I can see though, regarding double/triple
> clicks. First, evaluate the following:
> 
>   (define-prefix-command 'test)
>   (global-set-key [mouse-3] #'test)
>   (global-set-key [mouse-3 mouse-1] #'forward-word)
> 
> 1. Triple clicking mouse-3 results in a popup menu that seems like it
>    shouldn't appear, but this is also case when triple clicking
>    C-mouse-3 even without my patch. I'm not sure what it's doing there.
>    
> 2. Double clicking mouse-3 usually results in a mouse-3 double-mouse-3
>    sequence, instead of double-mouse-3. You can tell by also evaluating:
> 
>      (global-set-key [mouse-3 double-mouse-3] #'forward-line)
>      (global-set-key [double-mouse-3] #'goto-line)
> 
>    With the above key set, double clicking mouse-3 calls `forward-line',
>    and oddly enough _triple_ clicking mouse-3 calls `goto-line'. Here's what
>    `describe-key' has to say about triple clicking mouse-3:
> 
>      <double-mouse-3> (translated from <triple-down-mouse-3>
>      <triple-mouse-3>) runs the command goto-line
> 
>   I have no idea why that translation exists.
> 
> Do you have any ideas on how to solve these issues (especially getting
> double click to issue double-mouse-#)?

No ideas at the moment, but I think we should first decide whether we
want to allow mouse clicks as prefix keys.  What are the practical
gains that justify messing with read_char on this behalf?  We already
have the equivalent functionality via menus, right?

Not that I want to discourage you from digging into these issues ;-)

Thanks.