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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#29272: 26.0.90; "C-h k C-mouse-3" followed by menu selection asks fo


From: Alan Mackenzie
Subject: bug#29272: 26.0.90; "C-h k C-mouse-3" followed by menu selection asks for more keys
Date: Tue, 14 Nov 2017 20:54:49 +0000
User-agent: Mutt/1.7.2 (2016-11-26)

Hello, Eli.

On Sun, Nov 12, 2017 at 14:38:50 +0200, Eli Zaretskii wrote:
> > Date: Sun, 12 Nov 2017 13:23:49 +0200
> > From: Eli Zaretskii <eliz@gnu.org>

> > To reproduce:

> >   emacs -Q
> >   C-h k C-mouse-3

> > This pops up a Lisp Interaction Mode menu.  Select some item from the
> > menu.  The expected result is to show in *Help* the description of the
> > command selected from the menu.  Instead, you are prompted again for a
> > key or a mouse click.

> > "C-h l" shows this:

> >   C-h k [describe-key]
> >   <C-down-mouse-3> <indent-pp-sexp> <help-echo> <help-echo>

> > (I'm guessing help-echo comes from the menu items traversed by the
> > mouse while selecting the item.)

I would think so, too.

> I think those help-echo events are the reason.  We have this in
> help-read-key-sequence:

>           (while
>               (pcase (setq key (read-key-sequence "\
> Describe the following key, mouse click, or menu item: "))
>                 ((and (pred vectorp) (let `(,key0 . ,_) (aref key 0))
>                       (guard (symbolp key0)) (let keyname (symbol-name key0)))
>                  (if no-mouse-movement
>                      (string-match "mouse-movement" keyname)
>                    (and (string-match "\\(mouse\\|down\\|click\\|drag\\)"
>                                       keyname)
>                         (not (sit-for (/ double-click-time 1000.0) t)))))))

> What I think happens is that after the mouse-click event we get a
> help-echo event, which causes sit-for to exit with nil value, and we
> keep looping, because the loop expects only mouse events.

Yes.

> Alan, could you please take a look?  I think this was introduced by
> your changes in 10c0e1c (which you, no doubt, will have hard time
> recognizing among the code that meanwhile was completely refactored),
> which I think was an attempt to fix bug#22731 (not mentioned in the
> log message).  I think the changes failed to consider mouse clicks
> that invoke menu items.

You're not kidding about the refactoring.  ;-)

The following patch attempts to catch and filter out obtrusive events.
Could you try it out, please, even though it's not perfect (see below).
It's based on the emacs-26 branch:



diff --git a/lisp/help.el b/lisp/help.el
index fbb9fc8cbe..d119615180 100644
--- a/lisp/help.el
+++ b/lisp/help.el
@@ -728,11 +728,17 @@ help-read-key-sequence
 Describe the following key, mouse click, or menu item: "))
                 ((and (pred vectorp) (let `(,key0 . ,_) (aref key 0))
                       (guard (symbolp key0)) (let keyname (symbol-name key0)))
-                 (if no-mouse-movement
-                     (string-match "mouse-movement" keyname)
-                   (and (string-match "\\(mouse\\|down\\|click\\|drag\\)"
-                                      keyname)
-                        (not (sit-for (/ double-click-time 1000.0) t)))))))
+                 (or
+                  (and no-mouse-movement
+                       (string-match "mouse-movement" keyname))
+                  (and (string-match "\\(mouse\\|down\\|click\\|drag\\)"
+                                     keyname)
+                       (progn
+                         ;; Discard events (e.g. <help-echo>) which might
+                         ;; spuriously trigger the `sit-for'.
+                         (sleep-for 0.001)
+                         (while (read-event nil nil 0.001))
+                         (not (sit-for (/ double-click-time 1000.0) t))))))))
           (list
            key
            ;; If KEY is a down-event, read and include the


I think I've corrected what looks like a bug, there; even when
`no-mouse-movement' is non-nil (i.e. in C-h c), it should still check for
double clicks.

However, the problem is that in C-h k  C-mouse-3
<select-something-from-the-menus>, we get a spurious "translation"
message in *Help*, looking something like:

    <C-down-mouse-3> <file> <new-file> (translated from <mouse-1> <new-file>) at
    that spot runs the command find-file (found in global-map), which is an
    interactive compiled Lisp function in `files.el'.

That was from a Linux tty session using gpm.  In X, I got the message

    .... (translated from <C-down-mouse-3> <C-down-mouse-3> ....)

.  I don't believe this glitch has to do with my patch - I think it's
been there for some while, but this bug has prevented it being seen
before.

-- 
Alan Mackenzie (Nuremberg, Germany).





reply via email to

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