GNU bug report logs - #53170
29.0.50; Can't repetitively click next node button inside Info header line

Previous Next

Full log

Message #16 received at 53170 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: luangruo <at> yahoo.com, 53170 <at> debbugs.gnu.org
Subject: Re: bug#53170: 29.0.50;
 Can't repetitively click next node button inside Info header line
Date: Tue, 11 Jan 2022 15:26:17 +0200

> From: Juri Linkov <juri <at> linkov.net>
> Date: Tue, 11 Jan 2022 11:01:53 +0200
> Cc: 53170 <at> 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?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.