bug-gnu-emacs
[Top][All Lists]
Advanced

[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?

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]