bug#53170: 29.0.50; Can't repetitively click next node button inside Info header line

bug#53170: 29.0.50; Can't repetitively click next node button inside Info header line

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Starting from emacs -Q, say "C-h i m tramp RET", then click the text
that reads "Next: Overview".  As long as you don't move the mouse at
all, you won't be able to click that button again.

Thanks.

In GNU Emacs 29.0.50 (build 304, x86_64-pc-linux-gnu, GTK+ Version 3.24.30, cairo version 1.17.4)
 of 2022-01-11 built on trinity
Repository revision: c060e374a15b54ce7861896602961330f9aa58c6
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101003
System Description: Fedora Linux 35 (Workstation Edition)

Configured using:
 'configure --cache-file=/tmp/ccache --with-xinput2 --with-xwidgets'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LCMS2 LIBSELINUX LIBSYSTEMD LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG
RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS WEBP X11
XDBE XIM XINPUT2 XPM XWIDGETS GTK3 ZLIB

Important settings:
  value of $LANG: en_GB.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Info

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-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
  buffer-read-only: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr mule-util info emacsbug message mailcap
yank-media rmc puny dired dired-loaddefs rfc822 mml mml-sec
password-cache epa derived epg rfc6068 epg-config gnus-util
text-property-search time-date seq gv subr-x byte-opt bytecomp
byte-compile cconv mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader cl-loaddefs cl-lib sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils iso-transl tooltip
eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type
elisp-mode mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd
fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow
isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax
font-core term/tty-colors frame minibuffer 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 emoji-zwj charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget keymap hashtable-print-readable backquote threads
xwidget-internal dbusbind inotify lcms2 dynamic-setting
system-font-setting font-render-setting cairo move-toolbar gtk x-toolkit
xinput2 x multi-tty make-network-process emacs)

Memory information:
((conses 16 50917 11883)
 (symbols 48 6021 1)
 (strings 32 19743 2081)
 (string-bytes 1 738691)
 (vectors 16 11509)
 (vector-slots 8 165885 14569)
 (floats 8 23 49)
 (intervals 56 569 129)
 (buffers 992 11))

bug#53170: 29.0.50; Can't repetitively click next node button inside Info header line

[Juri Linkov]

> Starting from emacs -Q, say "C-h i m tramp RET", then click the text
> that reads "Next: Overview".  As long as you don't move the mouse at
> all, you won't be able to click that button again.

I guess this is the case when you click the mouse button too fast?
By default, mouse-1-click-follows-link is 450, and Info-link-keymap
uses such settings:

    (define-key keymap [mouse-2] 'Info-mouse-follow-link)
    (define-key keymap [follow-link] 'mouse-face)

bug#53170: 29.0.50; Can't repetitively click next node button inside Info header line

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Juri Linkov <juri@linkov.net> writes:

> I guess this is the case when you click the mouse button too fast?
> By default, mouse-1-click-follows-link is 450, and Info-link-keymap
> uses such settings:

>     (define-key keymap [mouse-2] 'Info-mouse-follow-link)
>     (define-key keymap [follow-link] 'mouse-face)

Hmm, that seems to be the case indeed.
I'm closing this bug, thanks.

bug#53170: 29.0.50; Can't repetitively click next node button inside Info header line

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Tue, 11 Jan 2022 11:01:53 +0200
> Cc: 53170@debbugs.gnu.org
> 
> > Starting from emacs -Q, say "C-h i m tramp RET", then click the text
> > that reads "Next: Overview".  As long as you don't move the mouse at
> > all, you won't be able to click that button again.
> 
> I guess this is the case when you click the mouse button too fast?
> By default, mouse-1-click-follows-link is 450, and Info-link-keymap
> uses such settings:
> 
>     (define-key keymap [mouse-2] 'Info-mouse-follow-link)
>     (define-key keymap [follow-link] 'mouse-face)

Sorry, I don't understand how these settings explain the issue.
AFAIU, the 450 msec is the time one need to _hold_ mouse-1 to make
such a long mouse-1 press be considered as meaning "move point here".
By contrast, what happens here is that 2 separate mouse-1 clicks, if
the time between them is too short, seem to have no effect at all:
Emacs neither follows the link nor does anything else.

So I suspect that something else is at work here, or maybe the effect
of mouse-1-click-follows-link is not documented accurately enough?

Can you explain the observed behavior in more detail given the above
defaults, please?  In particular, how come a feature that's
documented to affect only "click and hold" mouse gestures seems to
affect double-click?

bug#53170: 29.0.50; Can't repetitively click next node button inside Info header line

[Juri Linkov]

>> > Starting from emacs -Q, say "C-h i m tramp RET", then click the text
>> > that reads "Next: Overview".  As long as you don't move the mouse at
>> > all, you won't be able to click that button again.
>> 
>> I guess this is the case when you click the mouse button too fast?
>> By default, mouse-1-click-follows-link is 450, and Info-link-keymap
>> uses such settings:
>> 
>>     (define-key keymap [mouse-2] 'Info-mouse-follow-link)
>>     (define-key keymap [follow-link] 'mouse-face)
>
> Sorry, I don't understand how these settings explain the issue.
> AFAIU, the 450 msec is the time one need to _hold_ mouse-1 to make
> such a long mouse-1 press be considered as meaning "move point here".
> By contrast, what happens here is that 2 separate mouse-1 clicks, if
> the time between them is too short, seem to have no effect at all:
> Emacs neither follows the link nor does anything else.
>
> So I suspect that something else is at work here, or maybe the effect
> of mouse-1-click-follows-link is not documented accurately enough?
>
> Can you explain the observed behavior in more detail given the above
> defaults, please?  In particular, how come a feature that's
> documented to affect only "click and hold" mouse gestures seems to
> affect double-click?

The second click selects the word.  Could you arrange the Info dir buffer
such that clicking on a menu item opens another Info node, where the second
quickly pressed mouse button is on another menu?  Then you will see the effect.
It selects the word on the menu item, instead of navigating to the node
under the menu item.

bug#53170: 29.0.50; Can't repetitively click next node button inside Info header line

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: luangruo@yahoo.com,  53170@debbugs.gnu.org
> Date: Tue, 11 Jan 2022 20:24:02 +0200
> 
> >>     (define-key keymap [mouse-2] 'Info-mouse-follow-link)
> >>     (define-key keymap [follow-link] 'mouse-face)
> >
> > Sorry, I don't understand how these settings explain the issue.
> > AFAIU, the 450 msec is the time one need to _hold_ mouse-1 to make
> > such a long mouse-1 press be considered as meaning "move point here".
> > By contrast, what happens here is that 2 separate mouse-1 clicks, if
> > the time between them is too short, seem to have no effect at all:
> > Emacs neither follows the link nor does anything else.
> >
> > So I suspect that something else is at work here, or maybe the effect
> > of mouse-1-click-follows-link is not documented accurately enough?
> >
> > Can you explain the observed behavior in more detail given the above
> > defaults, please?  In particular, how come a feature that's
> > documented to affect only "click and hold" mouse gestures seems to
> > affect double-click?
> 
> The second click selects the word.

Why is it useful to select the word on the header line?  It doesn't do
anything useful, AFAICT.

> Could you arrange the Info dir buffer such that clicking on a menu
> item opens another Info node, where the second quickly pressed mouse
> button is on another menu?  Then you will see the effect.  It
> selects the word on the menu item, instead of navigating to the node
> under the menu item.

Which means that the documentation of mouse-1-click-follows-link is
completely off target, because it says nothing about its effect on
double-click!

This is yet another bad UI change, whereby seemingly insignificant
random factors in what the user does cause very significant changes in
behavior.  In general, this should be unacceptable from the UX POV.
While it could be tolerated when the user needs to press a mouse
button continuously for almost 0.5 sec to have the "unusual" effect,
it is IMO completely unacceptable when a quick double-click sometimes
is processed as two single clicks, and causes Emacs to do nothing if
the time interval is short enough.

I think we should undo this "feature", at least in Info.

bug#53170: 29.0.50; Can't repetitively click next node button inside Info header line

[Juri Linkov]

>> The second click selects the word.
>
> Why is it useful to select the word on the header line?

Sorry, I missed that this report is about the header line,
I thought it's about breadcrumbs.

Then these bindings are interfering:

    (define-key keymap [header-line down-mouse-1] 'mouse-drag-header-line)
    (define-key keymap [header-line mouse-1] 'mouse-select-window)

The problem can be fixed by replacing these lines with:

    (define-key keymap [header-line mouse-1] 'Info-mouse-follow-link)

But I don't know how important is the feature of selecting/dragging the header-line?

bug#53170: 29.0.50; Can't repetitively click next node button inside Info header line

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: luangruo@yahoo.com,  53170@debbugs.gnu.org
> Date: Tue, 11 Jan 2022 21:12:50 +0200
> 
> >> The second click selects the word.
> >
> > Why is it useful to select the word on the header line?
> 
> Sorry, I missed that this report is about the header line,
> I thought it's about breadcrumbs.
> 
> Then these bindings are interfering:
> 
>     (define-key keymap [header-line down-mouse-1] 'mouse-drag-header-line)
>     (define-key keymap [header-line mouse-1] 'mouse-select-window)
> 
> The problem can be fixed by replacing these lines with:
> 
>     (define-key keymap [header-line mouse-1] 'Info-mouse-follow-link)
> 
> But I don't know how important is the feature of selecting/dragging the header-line?

I don't think I understand how 2 clicks one after another are taken as
a drag-mouse event.  Can you tell why this happens?

bug#53170: 29.0.50; Can't repetitively click next node button inside Info header line

[Juri Linkov]

>> Then these bindings are interfering:
>>
>>     (define-key keymap [header-line down-mouse-1] 'mouse-drag-header-line)
>>     (define-key keymap [header-line mouse-1] 'mouse-select-window)
>>
>> The problem can be fixed by replacing these lines with:
>>
>>     (define-key keymap [header-line mouse-1] 'Info-mouse-follow-link)
>>
>> But I don't know how important is the feature of selecting/dragging the header-line?
>
> I don't think I understand how 2 clicks one after another are taken as
> a drag-mouse event.  Can you tell why this happens?

Actually, its's mouse-select-window that steals the click.
There is no need to bind mouse-1 to mouse-select-window
because the window is selected anyway, so this patch fixes
the reported problem:

diff --git a/lisp/info.el b/lisp/info.el
index f4f0f9790c..bb8cd0d312 100644
--- a/lisp/info.el
+++ b/lisp/info.el
@@ -4693,7 +4693,7 @@ Info-goto-emacs-key-command-node
 (defvar Info-link-keymap
   (let ((keymap (make-sparse-keymap)))
     (define-key keymap [header-line down-mouse-1] 'mouse-drag-header-line)
-    (define-key keymap [header-line mouse-1] 'mouse-select-window)
+    (define-key keymap [header-line mouse-1] 'Info-mouse-follow-link)
     (define-key keymap [header-line mouse-2] 'Info-mouse-follow-link)
     (define-key keymap [mouse-2] 'Info-mouse-follow-link)
     (define-key keymap [follow-link] 'mouse-face)
-- 

bug#53170: 29.0.50; Can't repetitively click next node button inside Info header line

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: luangruo@yahoo.com,  53170@debbugs.gnu.org
> Date: Wed, 12 Jan 2022 19:20:40 +0200
> 
> >> But I don't know how important is the feature of selecting/dragging the header-line?
> >
> > I don't think I understand how 2 clicks one after another are taken as
> > a drag-mouse event.  Can you tell why this happens?
> 
> Actually, its's mouse-select-window that steals the click.
> There is no need to bind mouse-1 to mouse-select-window
> because the window is selected anyway, so this patch fixes
> the reported problem:

Thanks, this LGTM.

bug#53170: 29.0.50; Can't repetitively click next node button inside Info header line

[Juri Linkov]

>> >> But I don't know how important is the feature of selecting/dragging the header-line?
>> >
>> > I don't think I understand how 2 clicks one after another are taken as
>> > a drag-mouse event.  Can you tell why this happens?
>> 
>> Actually, its's mouse-select-window that steals the click.
>> There is no need to bind mouse-1 to mouse-select-window
>> because the window is selected anyway, so this patch fixes
>> the reported problem:
>
> Thanks, this LGTM.

So now pushed to master.