[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#14793: 23.4; Cannot bind a function to a sequence of two mouse keys
From: |
Alex |
Subject: |
bug#14793: 23.4; Cannot bind a function to a sequence of two mouse keys |
Date: |
Wed, 04 Oct 2017 21:58:41 -0600 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
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.
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
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
Description: mouse prefix
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.