Subject: bug#29272: 26.0.90; "C-h k C-mouse-3" followed by menu selection asks for more keys

From: Eli Zaretskii <[email-masked]>
Date: Sun, 12 Nov 2017 14:38:50 +0200

> Date: Sun, 12 Nov 2017 13:23:49 +0200
> From: Eli Zaretskii <[email-masked]>
> 
> 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 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.

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.