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

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

[Eli Zaretskii]

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

This works in Emacs 25.2, so it's a recent regression.

In GNU Emacs 26.0.90 (build 1, i686-pc-mingw32)
 of 2017-10-12 built on HOME-C4E4A596F7
Windowing system distributor 'Microsoft Corp.', version 5.1.2600
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Type C-x 1 to delete the help window.

Configured using:
 'configure --prefix=/d/usr --with-wide-int --with-modules
 --enable-checking=yes,glyphs 'CFLAGS=-Og -gdwarf-4 -g3''

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB
TOOLKIT_SCROLL_BARS MODULES LCMS2

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1255

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny seq byte-opt gv
bytecomp byte-compile cconv dired dired-loaddefs format-spec rfc822 mml
mml-sec password-cache epa derived epg epg-config gnus-util rmail
rmail-loaddefs mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils cl-extra help-fns radix-tree help-mode
easymenu cl-loaddefs cl-lib elec-pair time-date mule-util tooltip eldoc
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel dos-w32
ls-lisp disp-table term/w32-win w32-win w32-vars term/common-win
tool-bar dnd fontset image regexp-opt fringe tabulated-list replace
newcomment text-mode elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow isearch timer select scroll-bar mouse jit-lock
font-lock syntax facemenu font-core term/tty-colors frame cl-generic
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote w32notify w32 lcms2
multi-tty make-network-process emacs)

Memory information:
((conses 16 103039 10652)
 (symbols 56 21441 1)
 (miscs 48 40 97)
 (strings 16 32209 1748)
 (string-bytes 1 779452)
 (vectors 16 14316)
 (vector-slots 8 648524 8150)
 (floats 8 52 222)
 (intervals 40 292 114)
 (buffers 880 12))

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

[Eli Zaretskii]

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

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

[Alan Mackenzie]

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

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

[Alan Mackenzie]

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

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

[Eli Zaretskii]

> Date: Tue, 14 Nov 2017 20:54:49 +0000
> Cc: 29272@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> You're not kidding about the refactoring.  ;-)

No, not at all.

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

Thanks, this seems to fix the problem.  I take it that you've verified
it doesn't re-introduce the original bug?

> 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 only see this in a text-mode frame (in my case it's "<mouse-1>
<indent-pp-sexp>").  On GUI frame, there's no "translation".

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

I think you are right, as I see the same problem in Emacs 24.5.

In any case, this is a much more minor bug than the one I reported, so
please install your changes on the release branch.  Bonus points if
you can find where does the "translation" come from.

Thanks.

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

[Alan Mackenzie]

Hello, Eli.

On Sat, Nov 18, 2017 at 13:27:35 +0200, Eli Zaretskii wrote:
> > Date: Tue, 14 Nov 2017 20:54:49 +0000
> > Cc: 29272@debbugs.gnu.org
> > From: Alan Mackenzie <acm@muc.de>

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

> Thanks, this seems to fix the problem.  I take it that you've verified
> it doesn't re-introduce the original bug?

> > 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 only see this in a text-mode frame (in my case it's "<mouse-1>
> <indent-pp-sexp>").  On GUI frame, there's no "translation".

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

> I think you are right, as I see the same problem in Emacs 24.5.

> In any case, this is a much more minor bug than the one I reported, so
> please install your changes on the release branch.

DONE.  Though I changed the timeout from 0.001s to 0.01s, because I'd had
a bit of trouble with the shorter timeout with edebug in operation.

> Bonus points if you can find where does the "translation" come from.

I understand that, now.  If I can fix bug #29349 (the one I reported this
morning about read_key_sequence not being properly recursive), I can fix
the problems here with C-mouse-3 on Linux TTYs with GPM.  There might
also be problems on MS-Windows, though I haven't been able to verify or
test this at all.

> Thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Alan Mackenzie]

Hello, Eli.

On Sat, Nov 18, 2017 at 13:27:35 +0200, Eli Zaretskii wrote:
> > Date: Tue, 14 Nov 2017 20:54:49 +0000
> > Cc: 29272@debbugs.gnu.org
> > From: Alan Mackenzie <acm@muc.de>

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

> Thanks, this seems to fix the problem.  I take it that you've verified
> it doesn't re-introduce the original bug?

> > 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 only see this in a text-mode frame (in my case it's "<mouse-1>
> <indent-pp-sexp>").  On GUI frame, there's no "translation".

Not on an X-Windows frame - X seems to handle all the mouse-movement and
intermediate click events itself.  On a linux tty with GPM, you do indeed
see these intermediate events.

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

> I think you are right, as I see the same problem in Emacs 24.5.

> In any case, this is a much more minor bug than the one I reported, so
> please install your changes on the release branch.  Bonus points if
> you can find where does the "translation" come from.

I claim my prize.  :-)

The following patch (which absolutely requires the patch to bug #29349
"read_key_sequence is only partially recursive.  This is a bug." to work)
fixes the above glitch on Linux tty (and possibly on other platforms).
It works by disregarding the "intermediate" events in UNTRANSLATED when
comparing the processed key sequence with the UNTRANSLATED string of
events:



diff --git a/lisp/help.el b/lisp/help.el
index 212e3679da..f5192e1902 100644
--- a/lisp/help.el
+++ b/lisp/help.el
@@ -583,14 +583,66 @@ where-is
 	  (princ string)))))
   nil)
 
+(defun help--equivalent-sequence-p (key untranslated)
+  "Is KEY a (possibly translated) version of UNTRANSLATED?
+If so return t, otherwise return nil.
+
+KEY is a key sequence, either a string or a vector.  UNTRANSLATED
+is a vector of events which gave rise to KEY, typically the output from
+`this-single-command-raw-keys'.
+
+The idea here is that for menu structure key sequences,
+UNTRANSLATED in certain environments contains things like
+<mouse-movement> and intermediate mouse button presses.  These
+will be disregarded in the comparison between KEY and
+UNTRANSLATED."
+  (let* ((len-key (length key))
+	 (len-unt (length untranslated))
+	 (key-idx 0)
+	 (unt-idx 0)
+	 key-elt unt-elt mods)
+    (cond
+     ((and (stringp key)
+	   (eq len-key len-unt))
+      (while (and (< key-idx len-key)
+		  (eq (aref key key-idx)
+		      (aref untranslated key-idx)))
+	(setq key-idx (1+ key-idx)))
+      (eq key-idx len-key))
+     ((vectorp key)
+      ;; In this while go round one elt of `key' each time round
+      (while
+	  (and (< key-idx len-key)
+	       (< unt-idx len-unt)
+	       (progn
+		 (setq key-elt (aref key key-idx))
+		 ;; In this while, skip an intermediate mouse click, etc.
+		 ;; from `untranslated' each time round.
+		 (while
+		     (and
+		      (< unt-idx len-unt)
+		      (progn
+			(setq unt-elt (aref untranslated unt-idx))
+			(not (eq unt-elt key-elt)))
+		      (progn
+			(setq mods (event-modifiers unt-elt))
+			(or (eq (car-safe unt-elt) 'mouse-movement)
+			    (cl-intersection '(click double triple drag down)
+					     mods))))
+		   (setq unt-idx (1+ unt-idx)))
+		 (eq unt-elt key-elt)))
+	(setq key-idx (1+ key-idx)
+	      unt-idx (1+ unt-idx)))
+      (eq key-idx len-key)))))
+
 (defun help-key-description (key untranslated)
   (let ((string (key-description key)))
     (if (or (not untranslated)
 	    (and (eq (aref untranslated 0) ?\e) (not (eq (aref key 0) ?\e))))
 	string
-      (let ((otherstring (key-description untranslated)))
-	(if (equal string otherstring)
-	    string
+      (if (help--equivalent-sequence-p key untranslated)
+          string
+        (let ((otherstring (key-description untranslated)))
 	  (format "%s (translated from %s)" string otherstring))))))
 
 (defun help--analyze-key (key untranslated)



> Thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Eli Zaretskii]

> Date: Sun, 19 Nov 2017 16:19:43 +0000
> Cc: 29272@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > In any case, this is a much more minor bug than the one I reported, so
> > please install your changes on the release branch.  Bonus points if
> > you can find where does the "translation" come from.
> 
> I claim my prize.  :-)
> 
> The following patch (which absolutely requires the patch to bug #29349
> "read_key_sequence is only partially recursive.  This is a bug." to work)
> fixes the above glitch on Linux tty (and possibly on other platforms).
> It works by disregarding the "intermediate" events in UNTRANSLATED when
> comparing the processed key sequence with the UNTRANSLATED string of
> events:

OK, but I still would like to understand where did that "translation"
come from.  I don't think I get that from the above description.

Thanks.

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

[Eli Zaretskii]

> Date: Sun, 19 Nov 2017 19:04:45 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 29272@debbugs.gnu.org
> 
> OK, but I still would like to understand where did that "translation"
> come from.  I don't think I get that from the above description.

Specifically, can you walk me through help-key-description, and tell
what values do you see there.  For example, where did mouse-1 come
from, if the original mouse click was C-mouse-3?  Isn't that the root
cause?

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

[Alan Mackenzie]

Hello, Eli.

On Sun, Nov 19, 2017 at 19:04:45 +0200, Eli Zaretskii wrote:
> > Date: Sun, 19 Nov 2017 16:19:43 +0000
> > Cc: 29272@debbugs.gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > In any case, this is a much more minor bug than the one I reported, so
> > > please install your changes on the release branch.  Bonus points if
> > > you can find where does the "translation" come from.

> > I claim my prize.  :-)

> > The following patch (which absolutely requires the patch to bug #29349
> > "read_key_sequence is only partially recursive.  This is a bug." to work)
> > fixes the above glitch on Linux tty (and possibly on other platforms).
> > It works by disregarding the "intermediate" events in UNTRANSLATED when
> > comparing the processed key sequence with the UNTRANSLATED string of
> > events:

> OK, but I still would like to understand where did that "translation"
> come from.  I don't think I get that from the above description.

It comes from the menu processing with GPM.  Each mouse click (but I'm
not sure about mouse movements) in a menu is entered into
read_key_sequence's raw event buffer.  This happens in the recursive call
of read_key_sequence which happens when r_k_s calls read_key, and a menu
gets processed.

> Thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Eli Zaretskii]

> Date: Sun, 19 Nov 2017 16:19:43 +0000
> Cc: 29272@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > I only see this in a text-mode frame (in my case it's "<mouse-1>
> > <indent-pp-sexp>").  On GUI frame, there's no "translation".
> 
> Not on an X-Windows frame - X seems to handle all the mouse-movement and
> intermediate click events itself.

Crystal ball says that your "X-Windows" is an Emacs build with some
toolkit.  I'm guessing that a non-toolkit build on X will have the
same problem as we see on text-mode frames, because in a non-toolkit
build Emacs handles all the mouse clicks in a menu.

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

[Alan Mackenzie]

Hello, Eli

On Sun, Nov 19, 2017 at 20:17:27 +0200, Eli Zaretskii wrote:
> > Date: Sun, 19 Nov 2017 16:19:43 +0000
> > Cc: 29272@debbugs.gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > I only see this in a text-mode frame (in my case it's "<mouse-1>
> > > <indent-pp-sexp>").  On GUI frame, there's no "translation".

> > Not on an X-Windows frame - X seems to handle all the mouse-movement and
> > intermediate click events itself.

> Crystal ball says that your "X-Windows" is an Emacs build with some
> toolkit.

Indeed.  The default GTK, I believe.  I usually work on a tty, so I've
never bothered too much about it.

> I'm guessing that a non-toolkit build on X will have the same problem
> as we see on text-mode frames, because in a non-toolkit build Emacs
> handles all the mouse clicks in a menu.

I suppose so.

Still, we're getting fixed on master.  I agree with you that it's too
big a change, and too small a bug to justify putting it on the release
branch.

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Noam Postavsky]

Alan Mackenzie <acm@muc.de> writes:

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

I've tested this after it was applied to emacs-26 [1: 22ff46e6d8]; the
bug is fixed in --with-x-toolkit=gtk build and w32 builds, but not in a
--with-x-toolkit=lucid build.

[1: 22ff46e6d8]: 2017-11-27 19:28:28 -0500
  ; Fix some comment typos
  https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=22ff46e6d85e3f023eb84ef7e8fe3de8947caf81

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

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  29272@debbugs.gnu.org
> Date: Tue, 28 Nov 2017 19:50:28 -0500
> 
> I've tested this after it was applied to emacs-26 [1: 22ff46e6d8]; the
> bug is fixed in --with-x-toolkit=gtk build and w32 builds, but not in a
> --with-x-toolkit=lucid build.

What happens in the Lucid build?

I don't understand why Lucid is different: the change is in the
platform-independent part of the code, AFAIU.

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

[martin rudalics]

 > What happens in the Lucid build?

Here menus with Lucid, Motif and pure X (without toolkit) builds behave
differently from GTK/Windows ones: They are immediately pulled down when
I release the mouse button.  So I have to continuously keep a mouse
button pressed during menu interaction (although I'm free to release any
modifier key).  Also, at least here, menu tooltips are broken - they
show an empty line only.  Only after the menu is pulled down, a correct
tooltip might appear, see below.

Else not much happens - I see in the echo area

Describe the following key, mouse click, or menu item: C-down-mouse-3-

and moving the mouse to some selectable item replaces that text by

Describe the following key, mouse click, or menu item:

sometimes resizing the echo area to two lines and displaying the correct
tooltip text after the menu was pulled down.  `view-lossage' doesn't
show anything of interest.


BTW: Could someone please fix that

(not (sit-for (/ double-click-time 1000.0) t))

form so it handles at least those values of `double-click-time'
described in its documentation:

   Maximum time between mouse clicks to make a double-click.
   Measured in milliseconds.  The value nil means disable double-click
   recognition; t means double-clicks have no time limit and are detected
   by position only.

I'm not sure what `sit-for' is supposed to return in those cases.

Thanks, martin

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

[Noam Postavsky]

From what I can tell, we should only need to wait for a double click
when we get a single mouse event; when clicking in a menu,
read-key-sequence returns [(C-down-mouse-3 (#<window ...> ...)) the-command].  The following
works for me in lucid and gtk:

--- c/lisp/help.el
+++ i/lisp/help.el
@@ -726,19 +726,19 @@ 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)))
-                 (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.01)
-                         (while (read-event nil nil 0.01))
-                         (not (sit-for (/ double-click-time 1000.0) t))))))))
+                (`[(,key0 . ,_)]
+                 (or (and no-mouse-movement (eq key0 'mouse-movement))
+                     ;; Wait long enough to fully read a double click event.
+                     ;; FIXME: How to handle double-click-time = t?
+                     (and (numberp double-click-time)
+                          (string-match "\\(mouse\\|down\\|click\\|drag\\)"
+                                        (symbol-name key0))
+                          (progn
+                            ;; Discard events (e.g. <help-echo>) which might
+                            ;; spuriously trigger the `sit-for'.
+                            (sleep-for 0.01)
+                            (while (read-event nil nil 0.01))
+                            (not (sit-for (/ double-click-time 1000.0) t))))))))
           (list
            key
            ;; If KEY is a down-event, read and include the


martin rudalics <rudalics@gmx.at> writes:

> BTW: Could someone please fix that
>
> (not (sit-for (/ double-click-time 1000.0) t))
>
> form so it handles at least those values of `double-click-time'
> described in its documentation:
>
>   Maximum time between mouse clicks to make a double-click.
>   Measured in milliseconds.  The value nil means disable double-click
>   recognition; t means double-clicks have no time limit and are detected
>   by position only.
>
> I'm not sure what `sit-for' is supposed to return in those cases.

I don't know how to handle the double-click-time = t case though.

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

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  acm@muc.de,  29272@debbugs.gnu.org
> Date: Wed, 29 Nov 2017 08:19:34 -0500
> 
> 
> The following works for me in lucid and gtk:
> 
> --- c/lisp/help.el
> +++ i/lisp/help.el
> @@ -726,19 +726,19 @@ 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)))
> -                 (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.01)
> -                         (while (read-event nil nil 0.01))
> -                         (not (sit-for (/ double-click-time 1000.0) t))))))))
> +                (`[(,key0 . ,_)]
> +                 (or (and no-mouse-movement (eq key0 'mouse-movement))
> +                     ;; Wait long enough to fully read a double click event.
> +                     ;; FIXME: How to handle double-click-time = t?
> +                     (and (numberp double-click-time)
> +                          (string-match "\\(mouse\\|down\\|click\\|drag\\)"
> +                                        (symbol-name key0))
> +                          (progn
> +                            ;; Discard events (e.g. <help-echo>) which might
> +                            ;; spuriously trigger the `sit-for'.
> +                            (sleep-for 0.01)
> +                            (while (read-event nil nil 0.01))
> +                            (not (sit-for (/ double-click-time 1000.0) t))))))))
>            (list
>             key
>             ;; If KEY is a down-event, read and include the
> 

LGTM, thanks

> > BTW: Could someone please fix that
> >
> > (not (sit-for (/ double-click-time 1000.0) t))
> >
> > form so it handles at least those values of `double-click-time'
> > described in its documentation:
> >
> >   Maximum time between mouse clicks to make a double-click.
> >   Measured in milliseconds.  The value nil means disable double-click
> >   recognition; t means double-clicks have no time limit and are detected
> >   by position only.
> >
> > I'm not sure what `sit-for' is supposed to return in those cases.
> 
> I don't know how to handle the double-click-time = t case though.

I think we should use some fixed time in that case.

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

[martin rudalics]

 > The following
 > works for me in lucid and gtk:

Works here wherever I tried it.

Thanks, martin

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

[Eli Zaretskii]

> Date: Wed, 29 Nov 2017 09:39:38 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: acm@muc.de, 29272@debbugs.gnu.org
> 
>  > What happens in the Lucid build?
> 
> Here menus with Lucid, Motif and pure X (without toolkit) builds behave
> differently from GTK/Windows ones: They are immediately pulled down when
> I release the mouse button.  So I have to continuously keep a mouse
> button pressed during menu interaction (although I'm free to release any
> modifier key).  Also, at least here, menu tooltips are broken - they
> show an empty line only.  Only after the menu is pulled down, a correct
> tooltip might appear, see below.
> 
> Else not much happens - I see in the echo area
> 
> Describe the following key, mouse click, or menu item: C-down-mouse-3-
> 
> and moving the mouse to some selectable item replaces that text by
> 
> Describe the following key, mouse click, or menu item:
> 
> sometimes resizing the echo area to two lines and displaying the correct
> tooltip text after the menu was pulled down.  `view-lossage' doesn't
> show anything of interest.

That means the same problem probably exists in a non-toolkit build.

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

[Alan Mackenzie]

Hello, Martin.

On Wed, Nov 29, 2017 at 09:39:38 +0100, martin rudalics wrote:

[ .... ]

> BTW: Could someone please fix that

> (not (sit-for (/ double-click-time 1000.0) t))

> form so it handles at least those values of `double-click-time'
> described in its documentation:

>    Maximum time between mouse clicks to make a double-click.
>    Measured in milliseconds.  The value nil means disable double-click
>    recognition; t means double-clicks have no time limit and are detected
>    by position only.

This is very strange indeed.  I wasn't aware of the t and nil values for
double-click-time, and of the six or seven uses of the variable in the
Emacs Lisp code, there are at least two other uses, possibly more, which
are likewise unaware of nil and t.

Looking at the change log, double-click-time was changed into a Lisp
variable, complete with values nil and t, by Jim Blandy in 1993, which
is hardly recent.  The documentation seems OK.

So why have so many programmers been oblivious to these values?

> I'm not sure what `sit-for' is supposed to return in those cases.

Presumably we shouldn't be calling sit-for for double-click-time nil and
t.  But, when does a key sequence consisting of mouse buttons end when
d-c-t is t?  This is a more important question, I think, for C-h c and
C-h k than for actually running commands.

Personally, I think the value t is a bad idea, and we should obsolete
it.  I can't see the use case.  Anybody who wants an indefinitely long
double-click-time can use a near infinite integer, in which case
anything that happens (or fails to happen) in C-h c and C-h k is her own
fault.  Surely, nobody is going to want to click the mouse, go off for a
cup of coffee, come back, then complete a double click.

Maybe we should interpret t as a moderately long finite interval, say 10
seconds.  That still leaves anybody the option of using a larger
interval.

> Thanks, martin

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Eli Zaretskii]

> Date: Wed, 29 Nov 2017 18:37:17 +0000
> Cc: Eli Zaretskii <eliz@gnu.org>,
>   Noam Postavsky <npostavs@users.sourceforge.net>, 29272@debbugs.gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> Personally, I think the value t is a bad idea, and we should obsolete
> it.

That's not going to fly.  We have absolutely no reason for making this
obsolete.

in any case, this discussion is not about double-click-time's purpose,
it's about what should "C-h k" when it is not a number.  I proposed a
practical solution; does anyone see a problem with it?

> Maybe we should interpret t as a moderately long finite interval, say 10
> seconds.

10 seconds is too long, I think 1 sec is much better.

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

[Alan Mackenzie]

Hello, Eli.

On Wed, Nov 29, 2017 at 20:56:30 +0200, Eli Zaretskii wrote:
> > Date: Wed, 29 Nov 2017 18:37:17 +0000
> > Cc: Eli Zaretskii <eliz@gnu.org>,
> >   Noam Postavsky <npostavs@users.sourceforge.net>, 29272@debbugs.gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > Personally, I think the value t is a bad idea, and we should obsolete
> > it.

> That's not going to fly.  We have absolutely no reason for making this
> obsolete.

> in any case, this discussion is not about double-click-time's purpose,
> it's about what should "C-h k" when it is not a number.  I proposed a
> practical solution; does anyone see a problem with it?

> > Maybe we should interpret t as a moderately long finite interval, say 10
> > seconds.

> 10 seconds is too long, I think 1 sec is much better.

I hope I'm not bikeshedding, but 1 second may be too little.  I'm
thinking about two use cases: (i) where a user's mouse button is almost
worn out, and it takes several attempted presses before one registers;
(ii) A disabled user who has physical difficulty in pressing the mouse
button, and needs that extra time to do so.  Either of these may be a
reason for setting double-click-time to t.

Maybe not as long as 10s.  How about compromising with the geometric
mean of 1s and 10s, namely 3.162s?

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Drew Adams]

> > 10 seconds is too long, I think 1 sec is much better.
> 
> I hope I'm not bikeshedding, but 1 second may be too little.  I'm
> thinking about two use cases: (i) where a user's mouse button is almost
> worn out, and it takes several attempted presses before one registers;
> (ii) A disabled user who has physical difficulty in pressing the mouse
> button, and needs that extra time to do so.  Either of these may be a
> reason for setting double-click-time to t.
> 
> Maybe not as long as 10s.  How about compromising with the geometric
> mean of 1s and 10s, namely 3.162s?

I hate to say it, but we probably need a user option (or at
least a variable) for this.  Users are different.  User hands
are different.  There is a reason that mouses are configurable
wrt speeds and delays.

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

[Eli Zaretskii]

> Date: Fri, 1 Dec 2017 11:18:05 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 29272@debbugs.gnu.org, npostavs@users.sourceforge.net
> 
> I hate to say it, but we probably need a user option (or at
> least a variable) for this.

We already have it: double-click-time.  This discussion is about users
who customized that to "infinity".

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

[martin rudalics]

 > This is very strange indeed.  I wasn't aware of the t and nil values for
 > double-click-time, and of the six or seven uses of the variable in the
 > Emacs Lisp code, there are at least two other uses, possibly more, which
 > are likewise unaware of nil and t.

Filed as Bug#23419.

martin

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

[Drew Adams]

> > I hate to say it, but we probably need a user option (or at
> > least a variable) for this.
> 
> We already have it: double-click-time.  This discussion is 
> about users who customized that to "infinity".

Well, I don't really want to get into a discussion here,
but to me, `double-click-time' should apply only to, well,
double-clicking.  This is not the same thing, IIUC.

But perhaps I missed something.  What is the proposed
`C-h k' behavior for users who have not customized
`double-click-time' to "infinity"?

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

[Eli Zaretskii]

> Date: Fri, 1 Dec 2017 13:12:39 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: acm@muc.de, 29272@debbugs.gnu.org, npostavs@users.sourceforge.net
> 
> > > I hate to say it, but we probably need a user option (or at
> > > least a variable) for this.
> > 
> > We already have it: double-click-time.  This discussion is 
> > about users who customized that to "infinity".
> 
> Well, I don't really want to get into a discussion here,
> but to me, `double-click-time' should apply only to, well,
> double-clicking.  This is not the same thing, IIUC.
> 
> But perhaps I missed something.

May I suggest reading the thread, to avoid missing things?

> What is the proposed `C-h k' behavior for users who have not
> customized `double-click-time' to "infinity"?

To wait that time for a next mouse gesture, before deciding on which
sequence to produce help.

Once  again, please read the discussion, the information is there.