* bug#53170: 29.0.50; Can't repetitively click next node button inside Info header line [not found] <877db7nhjn.fsf.ref@yahoo.com> @ 2022-01-11 2:16 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2022-01-11 9:01 ` Juri Linkov 0 siblings, 1 reply; 11+ messages in thread From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-01-11 2:16 UTC (permalink / raw) To: 53170 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)) ^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#53170: 29.0.50; Can't repetitively click next node button inside Info header line 2022-01-11 2:16 ` 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 @ 2022-01-11 9:01 ` Juri Linkov 2022-01-11 9:40 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2022-01-11 13:26 ` Eli Zaretskii 0 siblings, 2 replies; 11+ messages in thread From: Juri Linkov @ 2022-01-11 9:01 UTC (permalink / raw) To: Po Lu; +Cc: 53170 > 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) ^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#53170: 29.0.50; Can't repetitively click next node button inside Info header line 2022-01-11 9:01 ` Juri Linkov @ 2022-01-11 9:40 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2022-01-11 13:26 ` Eli Zaretskii 1 sibling, 0 replies; 11+ messages in thread From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-01-11 9:40 UTC (permalink / raw) To: Juri Linkov; +Cc: 53170-done 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#53170: 29.0.50; Can't repetitively click next node button inside Info header line 2022-01-11 9:01 ` Juri Linkov 2022-01-11 9:40 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-01-11 13:26 ` Eli Zaretskii 2022-01-11 18:24 ` Juri Linkov 1 sibling, 1 reply; 11+ messages in thread From: Eli Zaretskii @ 2022-01-11 13:26 UTC (permalink / raw) To: Juri Linkov; +Cc: luangruo, 53170 > 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? ^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#53170: 29.0.50; Can't repetitively click next node button inside Info header line 2022-01-11 13:26 ` Eli Zaretskii @ 2022-01-11 18:24 ` Juri Linkov 2022-01-11 18:55 ` Eli Zaretskii 0 siblings, 1 reply; 11+ messages in thread From: Juri Linkov @ 2022-01-11 18:24 UTC (permalink / raw) To: Eli Zaretskii; +Cc: luangruo, 53170 >> > 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#53170: 29.0.50; Can't repetitively click next node button inside Info header line 2022-01-11 18:24 ` Juri Linkov @ 2022-01-11 18:55 ` Eli Zaretskii 2022-01-11 19:12 ` Juri Linkov 0 siblings, 1 reply; 11+ messages in thread From: Eli Zaretskii @ 2022-01-11 18:55 UTC (permalink / raw) To: Juri Linkov; +Cc: luangruo, 53170 > 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#53170: 29.0.50; Can't repetitively click next node button inside Info header line 2022-01-11 18:55 ` Eli Zaretskii @ 2022-01-11 19:12 ` Juri Linkov 2022-01-11 20:03 ` Eli Zaretskii 0 siblings, 1 reply; 11+ messages in thread From: Juri Linkov @ 2022-01-11 19:12 UTC (permalink / raw) To: Eli Zaretskii; +Cc: luangruo, 53170 >> 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? ^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#53170: 29.0.50; Can't repetitively click next node button inside Info header line 2022-01-11 19:12 ` Juri Linkov @ 2022-01-11 20:03 ` Eli Zaretskii 2022-01-12 17:20 ` Juri Linkov 0 siblings, 1 reply; 11+ messages in thread From: Eli Zaretskii @ 2022-01-11 20:03 UTC (permalink / raw) To: Juri Linkov; +Cc: luangruo, 53170 > 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? ^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#53170: 29.0.50; Can't repetitively click next node button inside Info header line 2022-01-11 20:03 ` Eli Zaretskii @ 2022-01-12 17:20 ` Juri Linkov 2022-01-12 17:29 ` Eli Zaretskii 0 siblings, 1 reply; 11+ messages in thread From: Juri Linkov @ 2022-01-12 17:20 UTC (permalink / raw) To: Eli Zaretskii; +Cc: luangruo, 53170 >> 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) -- ^ permalink raw reply related [flat|nested] 11+ messages in thread
* bug#53170: 29.0.50; Can't repetitively click next node button inside Info header line 2022-01-12 17:20 ` Juri Linkov @ 2022-01-12 17:29 ` Eli Zaretskii 2022-01-24 18:56 ` Juri Linkov 0 siblings, 1 reply; 11+ messages in thread From: Eli Zaretskii @ 2022-01-12 17:29 UTC (permalink / raw) To: Juri Linkov; +Cc: luangruo, 53170 > 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#53170: 29.0.50; Can't repetitively click next node button inside Info header line 2022-01-12 17:29 ` Eli Zaretskii @ 2022-01-24 18:56 ` Juri Linkov 0 siblings, 0 replies; 11+ messages in thread From: Juri Linkov @ 2022-01-24 18:56 UTC (permalink / raw) To: Eli Zaretskii; +Cc: luangruo, 53170 >> >> 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2022-01-24 18:56 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <877db7nhjn.fsf.ref@yahoo.com>
2022-01-11 2:16 ` 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
2022-01-11 9:01 ` Juri Linkov
2022-01-11 9:40 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-01-11 13:26 ` Eli Zaretskii
2022-01-11 18:24 ` Juri Linkov
2022-01-11 18:55 ` Eli Zaretskii
2022-01-11 19:12 ` Juri Linkov
2022-01-11 20:03 ` Eli Zaretskii
2022-01-12 17:20 ` Juri Linkov
2022-01-12 17:29 ` Eli Zaretskii
2022-01-24 18:56 ` Juri Linkov
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).