unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 29272@debbugs.gnu.org
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	[thread overview]
Message-ID: <20171114205449.GA8025@ACM> (raw)
In-Reply-To: <83mv3rn02t.fsf@gnu.org>

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





  parent reply	other threads:[~2017-11-14 20:54 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-12 11:23 bug#29272: 26.0.90; "C-h k C-mouse-3" followed by menu selection asks for more keys Eli Zaretskii
2017-11-12 12:38 ` Eli Zaretskii
2017-11-12 13:24   ` Alan Mackenzie
2017-11-14 20:54   ` Alan Mackenzie [this message]
2017-11-18 11:27     ` Eli Zaretskii
2017-11-18 15:15       ` Alan Mackenzie
2017-11-19 16:19       ` Alan Mackenzie
2017-11-19 17:04         ` Eli Zaretskii
2017-11-19 17:44           ` Eli Zaretskii
2017-11-19 17:54           ` Alan Mackenzie
2017-11-19 18:17         ` Eli Zaretskii
2017-11-19 20:26           ` Alan Mackenzie
2017-11-29  0:50     ` Noam Postavsky
2017-11-29  3:38       ` Eli Zaretskii
2017-11-29  8:39         ` martin rudalics
2017-11-29 13:19           ` Noam Postavsky
2017-11-29 17:53             ` Eli Zaretskii
2017-11-30  7:22             ` martin rudalics
2017-11-29 17:55           ` Eli Zaretskii
2017-11-29 18:37           ` Alan Mackenzie
2017-11-29 18:56             ` Eli Zaretskii
2017-12-01 16:57               ` Alan Mackenzie
2017-12-01 19:18                 ` Drew Adams
2017-12-01 19:43                   ` Eli Zaretskii
2017-11-30  7:22             ` martin rudalics
     [not found] <<83shdjn3ju.fsf@gnu.org>
     [not found] ` <<83mv3rn02t.fsf@gnu.org>
     [not found]   ` <<20171114205449.GA8025@ACM>
     [not found]     ` <<87fu8xnc17.fsf@users.sourceforge.net>
     [not found]       ` <<83h8td4uw5.fsf@gnu.org>
     [not found]         ` <<5A1E724A.5030507@gmx.at>
     [not found]           ` <<20171129183717.GA8914@ACM>
     [not found]             ` <<83609s52xt.fsf@gnu.org>
     [not found]               ` <<20171201165740.GE3840@ACM>
     [not found]                 ` <<1c4abffb-e975-41b1-a368-29518bc3b360@default>
     [not found]                   ` <<83y3mm1bfu.fsf@gnu.org>
2017-12-01 21:12                     ` Drew Adams
2017-12-02  8:13                       ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171114205449.GA8025@ACM \
    --to=acm@muc.de \
    --cc=29272@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).