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: Sun, 12 Nov 2017 13:24:08 +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 <address@hidden>

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

Will do.

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

That could well be the case.  I'll be looking at it.

-- 
Alan Mackenzie (Nuremberg, Germany).





reply via email to

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