GNU bug report logs - #14793
23.4; Cannot bind a function to a sequence of two mouse keys

Previous Next

To reply to this bug, email your comments to 14793 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lodi <regularclockwork <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 23.4; Cannot bind a function to a sequence of two mouse keys
Date: Thu, 4 Jul 2013 19:14:35 +0200

[Message part 1 (text/plain, inline)]

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

[Message part 2 (text/html, inline)]

Message #8 received at 14793 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lodi <regularclockwork <at> gmail.com>
To: 14793 <at> debbugs.gnu.org
Subject: Further important info
Date: Thu, 4 Jul 2013 22:12:08 +0200

[Message part 1 (text/plain, inline)]

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

[Message part 2 (text/html, inline)]

Message #15 received at 14793 <at> debbugs.gnu.org (full text, mbox):

From: Alex <agrambot <at> gmail.com>
To: eliz <at> gnu.org
Cc: 14793 <at> debbugs.gnu.org, regularclockwork <at> gmail.com,
 npostavs <at> users.sourceforge.net
Subject: Re: bug#14793: 23.4;
 Cannot bind a function to a sequence of two mouse keys
Date: Sat, 30 Sep 2017 21:05:05 -0600

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.

Message #18 received at 14793 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alex <agrambot <at> gmail.com>
Cc: 14793 <at> debbugs.gnu.org, regularclockwork <at> gmail.com,
 npostavs <at> users.sourceforge.net
Subject: Re: bug#14793: 23.4;
 Cannot bind a function to a sequence of two mouse keys
Date: Sun, 01 Oct 2017 19:02:11 +0300

> From: Alex <agrambot <at> gmail.com>
> Cc: 14793 <at> debbugs.gnu.org, npostavs <at> users.sourceforge.net, regularclockwork <at> 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?

Message #21 received at 14793 <at> debbugs.gnu.org (full text, mbox):

From: Alex <agrambot <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 14793 <at> debbugs.gnu.org, regularclockwork <at> gmail.com,
 npostavs <at> users.sourceforge.net
Subject: Re: bug#14793: 23.4;
 Cannot bind a function to a sequence of two mouse keys
Date: Sun, 01 Oct 2017 11:53:16 -0600

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Alex <agrambot <at> gmail.com>
>> Cc: 14793 <at> debbugs.gnu.org, npostavs <at> users.sourceforge.net, regularclockwork <at> 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)

Message #24 received at 14793 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alex <agrambot <at> gmail.com>
Cc: 14793 <at> debbugs.gnu.org, regularclockwork <at> gmail.com,
 npostavs <at> users.sourceforge.net
Subject: Re: bug#14793: 23.4;
 Cannot bind a function to a sequence of two mouse keys
Date: Sun, 01 Oct 2017 21:26:53 +0300

> From: Alex <agrambot <at> gmail.com>
> Cc: 14793 <at> debbugs.gnu.org,  npostavs <at> users.sourceforge.net,  regularclockwork <at> 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.

Message #27 received at 14793 <at> debbugs.gnu.org (full text, mbox):

From: Alex <agrambot <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 14793 <at> debbugs.gnu.org, regularclockwork <at> gmail.com,
 npostavs <at> users.sourceforge.net
Subject: Re: bug#14793: 23.4;
 Cannot bind a function to a sequence of two mouse keys
Date: Mon, 02 Oct 2017 21:59:37 -0600

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Alex <agrambot <at> gmail.com>
>> Cc: 14793 <at> debbugs.gnu.org,  npostavs <at> users.sourceforge.net,  regularclockwork <at> 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?

Message #30 received at 14793 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alex <agrambot <at> gmail.com>
Cc: 14793 <at> debbugs.gnu.org, regularclockwork <at> gmail.com,
 npostavs <at> users.sourceforge.net
Subject: Re: bug#14793: 23.4;
 Cannot bind a function to a sequence of two mouse keys
Date: Tue, 03 Oct 2017 17:33:06 +0300

> From: Alex <agrambot <at> gmail.com>
> Cc: 14793 <at> debbugs.gnu.org,  npostavs <at> users.sourceforge.net,  regularclockwork <at> 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.

Message #33 received at 14793 <at> debbugs.gnu.org (full text, mbox):

From: Alex <agrambot <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 14793 <at> debbugs.gnu.org, regularclockwork <at> gmail.com,
 npostavs <at> users.sourceforge.net
Subject: Re: bug#14793: 23.4;
 Cannot bind a function to a sequence of two mouse keys
Date: Wed, 04 Oct 2017 21:58:41 -0600

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Alex <agrambot <at> gmail.com>
>> Cc: 14793 <at> debbugs.gnu.org,  npostavs <at> users.sourceforge.net,  regularclockwork <at> 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.

[mouse.diff (text/x-diff, inline)]

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

[Message part 3 (text/plain, inline)]

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?

[0001-Allow-mouse-clicks-to-be-prefix-keys-Bug-14793.patch (text/x-diff, attachment)]

[Message part 5 (text/plain, inline)]

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.

Message #36 received at 14793 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alex <agrambot <at> gmail.com>
Cc: 14793 <at> debbugs.gnu.org, regularclockwork <at> gmail.com,
 npostavs <at> users.sourceforge.net
Subject: Re: bug#14793: 23.4;
 Cannot bind a function to a sequence of two mouse keys
Date: Thu, 05 Oct 2017 10:55:11 +0300

> From: Alex <agrambot <at> gmail.com>
> Cc: 14793 <at> debbugs.gnu.org,  npostavs <at> users.sourceforge.net,  regularclockwork <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.