GNU bug report logs -
#14793
23.4; Cannot bind a function to a sequence of two mouse keys
Previous Next
Full log
Message #33 received at 14793 <at> debbugs.gnu.org (full text, mbox):
[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.
This bug report was last modified 7 years and 254 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.