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

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

[Stefano Lodi]

[-- Attachment #1: Type: text/plain, Size: 1997 bytes --]

This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your report will be posted to the bug-gnu-emacs@gnu.org mailing list
and the gnu.emacs.bug news group, and at http://debbugs.gnu.org.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug.  If you can, give
a recipe starting from `emacs -Q':

The manual states at the end of Section 48.3.10 "Rebinding Mouse Buttons"
says "You can put more than one mouse button in a key sequence, but it
isn't usual to do so."

I failed to bind a simple function to a sequence of two mouse keys.

> emacs -Q

inside the *scratch* buffer, evaluate:

(defun go-backwards ()
            "Go backward one word."
            (interactive)
            (backward-word 1))
(global-unset-key [mouse-3])
(global-set-key [mouse-3 mouse-2] 'go-backwards)

Now, pressing the right mouse button gives the message

Empty menu

at the bottom of the Emacs screen.

If I evaluate

(setq debug-on-error t)

and press the right button again I get just

Debugger entered--Lisp error: (error "Empty menu")

However, after evaluating

(global-set-key [mouse-3] 'go-backwards)

pressing the right mouse button does indeed move the point backward one
word; therefore binding a single mouse key works.

Another way to obtain the same result is the following.

Evaluate

(defun go-backwards ()
            "Go backward one word."
            (interactive)
            (backward-word 1))
(global-unset-key [mouse-3])
(defvar my-map (make-sparse-keymap))
(define-key my-map [mouse-2] 'go-backwards)

Now, C-h v my-map gives clearly

my-map's value is (keymap
 (mouse-2 . go-backwards))

Then evaluating

(define-key global-map [mouse-3] my-map)

gives

(keymap (mouse-2 . go-backwards))

at the bottom of the Emacs screen. However, again the right button gives
"Empty menu".

[-- Attachment #2: Type: text/html, Size: 2624 bytes --]

bug#14793: Further important info

[Stefano Lodi]

[-- Attachment #1: Type: text/plain, Size: 66 bytes --]

I forgot to mention that the bug described happens also in trunk.

[-- Attachment #2: Type: text/html, Size: 91 bytes --]

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

[Alex]

Eli, do you know how to solve this?

Try this:

(define-prefix-command 'test)
(global-set-key (kbd "C-t") #'test)
(global-set-key [mouse-3] #'test)
(global-set-key (kbd "C-t <mouse-2>") #'backward-word)
(global-set-key [mouse-3 mouse-2] #'backward-word)

Hitting C-t mouse-2 calls `backward-word' as intended, but hitting
mouse-3 mouse-2 displays an "Empty menu" error as in the original
report.

The error is thrown from Fx_popup_menu and is called from
read_char_x_menu_prompt, which is only called in the mouse case. I'm not
sure how to proceed from here.

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

[Eli Zaretskii]

> From: Alex <agrambot@gmail.com>
> Cc: 14793@debbugs.gnu.org, npostavs@users.sourceforge.net, regularclockwork@gmail.com
> Date: Sat, 30 Sep 2017 21:05:05 -0600
> 
> (define-prefix-command 'test)
> (global-set-key (kbd "C-t") #'test)
> (global-set-key [mouse-3] #'test)
> (global-set-key (kbd "C-t <mouse-2>") #'backward-word)
> (global-set-key [mouse-3 mouse-2] #'backward-word)
> 
> Hitting C-t mouse-2 calls `backward-word' as intended, but hitting
> mouse-3 mouse-2 displays an "Empty menu" error as in the original
> report.
> 
> The error is thrown from Fx_popup_menu and is called from
> read_char_x_menu_prompt, which is only called in the mouse case. I'm not
> sure how to proceed from here.

Who said a mouse click could be a prefix key?

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

[Alex]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Alex <agrambot@gmail.com>
>> Cc: 14793@debbugs.gnu.org, npostavs@users.sourceforge.net, regularclockwork@gmail.com
>> Date: Sat, 30 Sep 2017 21:05:05 -0600
>> 
>> (define-prefix-command 'test)
>> (global-set-key (kbd "C-t") #'test)
>> (global-set-key [mouse-3] #'test)
>> (global-set-key (kbd "C-t <mouse-2>") #'backward-word)
>> (global-set-key [mouse-3 mouse-2] #'backward-word)
>> 
>> Hitting C-t mouse-2 calls `backward-word' as intended, but hitting
>> mouse-3 mouse-2 displays an "Empty menu" error as in the original
>> report.
>> 
>> The error is thrown from Fx_popup_menu and is called from
>> read_char_x_menu_prompt, which is only called in the mouse case. I'm not
>> sure how to proceed from here.
>
> Who said a mouse click could be a prefix key?

Does the manual state that a mouse click can't be a prefix key? "(elisp)
Prefix Keys" states that "A prefix key is a key sequence whose binding
is a keymap", which mouse-3 as above satisfies:

(keymapp (key-binding [mouse-3])) => t

As long as the mouse click isn't in some special area (mode-line,
menu-bar, etc.), then I would hope that it would be treated as a prefix
key.

Also, "(emacs) Mouse Buttons" states that "You can put more than one
mouse button in a key sequence, but it isn’t usual to do so.".

How would one do this if a mouse click can't be a prefix key? The
following also fails:

(define-prefix-command 'test)
(global-set-key (kbd "C-t") #'test)
(global-set-key (kbd "C-t <mouse-3> <mouse-2>") #'backward-word)

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

[Eli Zaretskii]

> From: Alex <agrambot@gmail.com>
> Cc: 14793@debbugs.gnu.org,  npostavs@users.sourceforge.net,  regularclockwork@gmail.com
> Date: Sun, 01 Oct 2017 11:53:16 -0600
> 
> > Who said a mouse click could be a prefix key?
> 
> Does the manual state that a mouse click can't be a prefix key?

If you are arguing that the manual is incomplete or inaccurate, I
could agree, but that's a different/separate issue, I'm sure.  Fixing
the docs is easy.

I just asked that question because my reading of the code is that this
is not supported.  Maybe I'm misreading: keyboard.c:read_char is not
for the faint at heart.

> Also, "(emacs) Mouse Buttons" states that "You can put more than one
> mouse button in a key sequence, but it isn’t usual to do so.".
> 
> How would one do this if a mouse click can't be a prefix key?

By making a menu, I presume.

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

[Alex]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Alex <agrambot@gmail.com>
>> Cc: 14793@debbugs.gnu.org,  npostavs@users.sourceforge.net,  regularclockwork@gmail.com
>> Date: Sun, 01 Oct 2017 11:53:16 -0600
>> 
>> > Who said a mouse click could be a prefix key?
>> 
>> Does the manual state that a mouse click can't be a prefix key?
>
> If you are arguing that the manual is incomplete or inaccurate, I
> could agree, but that's a different/separate issue, I'm sure.  Fixing
> the docs is easy.

If it turns out that mouse clicks can't be prefix keys, then the doc
should indeed be fixed.

> I just asked that question because my reading of the code is that this
> is not supported.  Maybe I'm misreading: keyboard.c:read_char is not
> for the faint at heart.

Yeah, I'm having trouble going through it. Is there a way to make it
supported, though? For example, what about catching the error around
read_char_x_menu_prompt (keyboard.c:L2683) and not exiting if an error
was thrown? I'm not sure how to go about this in C.

>> Also, "(emacs) Mouse Buttons" states that "You can put more than one
>> mouse button in a key sequence, but it isn’t usual to do so.".
>> 
>> How would one do this if a mouse click can't be a prefix key?
>
> By making a menu, I presume.

Do you mean those mentioned in "(emacs) Menu Mouse Clicks"? Does
clicking in those menus count as key sequences?

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

[Eli Zaretskii]

> From: Alex <agrambot@gmail.com>
> Cc: 14793@debbugs.gnu.org,  npostavs@users.sourceforge.net,  regularclockwork@gmail.com
> Date: Mon, 02 Oct 2017 21:59:37 -0600
> 
> > I just asked that question because my reading of the code is that this
> > is not supported.  Maybe I'm misreading: keyboard.c:read_char is not
> > for the faint at heart.
> 
> Yeah, I'm having trouble going through it. Is there a way to make it
> supported, though? For example, what about catching the error around
> read_char_x_menu_prompt (keyboard.c:L2683) and not exiting if an error
> was thrown?

That's hardly a clean solution.  A clean solution would avoid calling
Fx_popup_menu when it detects the situation we are talking about.

> >> Also, "(emacs) Mouse Buttons" states that "You can put more than one
> >> mouse button in a key sequence, but it isn’t usual to do so.".
> >> 
> >> How would one do this if a mouse click can't be a prefix key?
> >
> > By making a menu, I presume.
> 
> Do you mean those mentioned in "(emacs) Menu Mouse Clicks"? Does
> clicking in those menus count as key sequences?

Yes, of course.  You can see that with "C-h l", for example.  Also,
every non-leaf menu item is a keymap.

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

[Alex]

[-- Attachment #1: Type: text/plain, Size: 2192 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Alex <agrambot@gmail.com>
>> Cc: 14793@debbugs.gnu.org,  npostavs@users.sourceforge.net,  regularclockwork@gmail.com
>> Date: Mon, 02 Oct 2017 21:59:37 -0600
>> 
>> > I just asked that question because my reading of the code is that this
>> > is not supported.  Maybe I'm misreading: keyboard.c:read_char is not
>> > for the faint at heart.
>> 
>> Yeah, I'm having trouble going through it. Is there a way to make it
>> supported, though? For example, what about catching the error around
>> read_char_x_menu_prompt (keyboard.c:L2683) and not exiting if an error
>> was thrown?
>
> That's hardly a clean solution.  A clean solution would avoid calling
> Fx_popup_menu when it detects the situation we are talking about.

Right, I just figured it was the easiest way to check if the rest of the
code supported prefix mouse clicks, but maybe it isn't for C. In any
case, I have a possible solution below.

>> >> Also, "(emacs) Mouse Buttons" states that "You can put more than one
>> >> mouse button in a key sequence, but it isn’t usual to do so.".
>> >> 
>> >> How would one do this if a mouse click can't be a prefix key?
>> >
>> > By making a menu, I presume.
>> 
>> Do you mean those mentioned in "(emacs) Menu Mouse Clicks"? Does
>> clicking in those menus count as key sequences?
>
> Yes, of course.  You can see that with "C-h l", for example.  Also,
> every non-leaf menu item is a keymap.

Ah, I see it now. It seems that it depends on the menu (the binding for
C-down-mouse-1 isn't a keymap, but C-down-mouse-2's is, which is
important for below).

Anyway, I tried out the following diff, which is based on the condition
at xmenu.c:L1460. The problem is that it uses the global variable
`menu_items_used', which is incremented during the execution of
Fx_popup_menu (keymap_panes). So the diff uses the value of
`menu_items_used' of the previously called menu. With the diff, you can
see that pressing C-down-mouse-2 right after startup leads to an
undefined key message instead of opening a menu; after pressing
C-down-mouse-1, though, pressing C-down-mouse-2 opens its menu properly.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: simple diff --]
[-- Type: text/x-diff, Size: 578 bytes --]

diff --git a/src/keyboard.c b/src/keyboard.c
index e8701b8870..5f92807087 100644
--- a/src/keyboard.c
+++ b/src/keyboard.c
@@ -2678,7 +2678,8 @@ read_char (int commandflag, Lisp_Object map,
       && !EQ (XCAR (prev_event), Qmenu_bar)
       && !EQ (XCAR (prev_event), Qtool_bar)
       /* Don't bring up a menu if we already have another event.  */
-      && !CONSP (Vunread_command_events))
+      && !CONSP (Vunread_command_events)
+      && menu_items_used > MENU_ITEMS_PANE_LENGTH)
     {
       c = read_char_x_menu_prompt (map, prev_event, used_mouse_menu);
 
-- 
2.14.2

[-- Attachment #3: Type: text/plain, Size: 182 bytes --]



I've attached a patch that seems to work for single clicks. I had to
move Fx_popup_menu's implementation outside of DEFUN so I could use
used_mouse_menu in it. What do you think?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: mouse prefix --]
[-- Type: text/x-diff, Size: 3623 bytes --]

From d001740b0f59cdc2165d62e05c7f2cb5ff8ab6b4 Mon Sep 17 00:00:00 2001
From: Alexander Gramiak <agrambot@gmail.com>
Date: Tue, 3 Oct 2017 17:11:08 -0600
Subject: [PATCH] Allow mouse clicks to be prefix keys (Bug#14793)

* src/keyboard.c (read_char): Check used_mouse_menu after calling
read_char_x_menu_prompt.
(read_char_x_menu_prompt): Pass used_mouse_menu to x_popup_menu and
return nil if it wasn't set to true.
* src/menu.c (Fx_popup_menu): Extract into a new function.
(x_popup_menu): New function. Don't error if used_mouse_menu is null,
and set used_mouse_menu if there was no error.
* src/keyboard.h: Declare x_popup_menu.
---
 src/keyboard.c | 21 +++++++++++++--------
 src/keyboard.h |  3 +++
 src/menu.c     | 11 ++++++++++-
 3 files changed, 26 insertions(+), 9 deletions(-)

diff --git a/src/keyboard.c b/src/keyboard.c
index e8701b8870..5912f89115 100644
--- a/src/keyboard.c
+++ b/src/keyboard.c
@@ -2682,11 +2682,15 @@ read_char (int commandflag, Lisp_Object map,
     {
       c = read_char_x_menu_prompt (map, prev_event, used_mouse_menu);
 
-      /* Now that we have read an event, Emacs is not idle.  */
-      if (!end_time)
-	timer_stop_idle ();
+      /* Only exit if a mouse menu was actually used successfully.  */
+      if (*used_mouse_menu)
+        {
+          /* Now that we have read an event, Emacs is not idle.  */
+          if (!end_time)
+            timer_stop_idle ();
 
-      goto exit;
+          goto exit;
+        }
     }
 
   /* Maybe autosave and/or garbage collect due to idleness.  */
@@ -8457,8 +8461,11 @@ read_char_x_menu_prompt (Lisp_Object map,
       /* Display the menu and get the selection.  */
       Lisp_Object value;
 
-      value = Fx_popup_menu (prev_event, get_keymap (map, 0, 1));
-      if (CONSP (value))
+      value = x_popup_menu (prev_event, get_keymap (map, 0, 1), used_mouse_menu);
+
+      if (!*used_mouse_menu)
+        value = Qnil;
+      else if (CONSP (value))
 	{
 	  Lisp_Object tem;
 
@@ -8489,8 +8496,6 @@ read_char_x_menu_prompt (Lisp_Object map,
 	}
       else if (NILP (value))
 	value = Qt;
-      if (used_mouse_menu)
-	*used_mouse_menu = true;
       return value;
     }
   return Qnil ;
diff --git a/src/keyboard.h b/src/keyboard.h
index a2a5f8f21d..954485c78b 100644
--- a/src/keyboard.h
+++ b/src/keyboard.h
@@ -360,6 +360,9 @@ enum menu_item_idx
 
 extern void unuse_menu_items (void);
 
+extern Lisp_Object
+x_popup_menu (Lisp_Object position, Lisp_Object menu, bool *used_mouse_menu);
+
 /* This is how to deal with multibyte text if HAVE_MULTILINGUAL_MENU
    isn't defined.  The use of HAVE_MULTILINGUAL_MENU could probably be
    confined to an extended version of this with sections of code below
diff --git a/src/menu.c b/src/menu.c
index d569b4b29b..257c67f6a4 100644
--- a/src/menu.c
+++ b/src/menu.c
@@ -1157,6 +1157,12 @@ keyboard input, then this normally results in a quit and
 event (indicating that the user invoked the menu with the mouse) then
 no quit occurs and `x-popup-menu' returns nil.  */)
   (Lisp_Object position, Lisp_Object menu)
+{
+  return x_popup_menu (position, menu, NULL);
+}
+
+Lisp_Object
+x_popup_menu (Lisp_Object position, Lisp_Object menu, bool *used_mouse_menu)
 {
   Lisp_Object keymap, tem, tem2;
   int xpos = 0, ypos = 0;
@@ -1439,7 +1445,10 @@ no quit occurs and `x-popup-menu' returns nil.  */)
     FRAME_DISPLAY_INFO (f)->grabbed = 0;
 #endif
 
-  if (error_name) error ("%s", error_name);
+  if (error_name && !used_mouse_menu)
+    error ("%s", error_name);
+  else if (!error_name && used_mouse_menu)
+    *used_mouse_menu = true;
   return selection;
 }
 
-- 
2.14.2


[-- Attachment #5: Type: text/plain, Size: 1248 bytes --]



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-#)? If not, maybe I'll fiddle around
with read_key_sequence later.

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

[Eli Zaretskii]

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