* bug#30955: 27.0.50; Mouse clicks on header-line in Info are broken @ 2018-03-26 14:54 Eli Zaretskii 2018-03-27 18:46 ` Stefan Monnier 0 siblings, 1 reply; 17+ messages in thread From: Eli Zaretskii @ 2018-03-26 14:54 UTC (permalink / raw) To: 30955 To reproduce: emacs -Q C-u C-h i /path/to/info/elisp.info RET 2 3 4 Click mouse-1 on the "Up: Programming Types" link on the header-line This results in an error: <header-line> <header-line> <mouse-2> is undefined If you now type "C-h c" followed by the same mouse-1 click, you will see <header-line> <down-mouse-1> (translated from <down-mouse-1>) at that spot runs the command mouse-drag-header-line as expected, but before that, momentarily, the echo area will flash this: header-line header-line mouse-2- Reverting the following commit fixes the problem: commit 3d5e31eceb9dc1fb62b2b27bcab549df3bd04ce9 Author: Stefan Monnier <monnier@iro.umontreal.ca> AuthorDate: Tue Jan 30 12:41:29 2018 -0500 Commit: Stefan Monnier <monnier@iro.umontreal.ca> CommitDate: Tue Jan 30 12:41:29 2018 -0500 * lisp/mouse.el: Rework the mouse-1-click remapping Avoid peeking ahead at the next event because this had undesirable effects, such as making 'this-single-command-raw-keys' return bogus information. (mouse--last-down): New variable. (mouse--down-1-maybe-follows-link): Don't do the remapping here. Instead, just keep track of the time when the down happened. (mouse--down-1-maybe-follows-link): Do the remapping here. (key-translation-map): Add bindings for (double-)mouse-1. In GNU Emacs 27.0.50 (build 169, i686-pc-mingw32) of 2018-03-25 built on HOME-C4E4A596F7 Repository revision: 1be6a21fd8b5ade67f7f69f964331aa570623683 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. <header-line> <header-line> <mouse-2> is undefined Configured using: 'configure --prefix=/d/usr --enable-checking=yes,glyphs --with-wide-int --with-modules --enable-check-lisp-object-type 'CFLAGS=-O0 -gdwarf-4 -g3'' Configured features: XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS MODULES THREADS JSON LCMS2 Important settings: value of $LANG: ENU locale-coding-system: cp1255 Major mode: Info Minor modes in effect: tooltip-mode: t global-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 auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t buffer-read-only: 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 cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils info easymenu time-date elec-pair 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 132974 9857) (symbols 56 21395 1) (miscs 48 58 152) (strings 16 36869 2443) (string-bytes 1 867215) (vectors 16 15422) (vector-slots 8 580149 18798) (floats 8 59 58) (intervals 40 4939 217) (buffers 880 13)) ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#30955: 27.0.50; Mouse clicks on header-line in Info are broken 2018-03-26 14:54 bug#30955: 27.0.50; Mouse clicks on header-line in Info are broken Eli Zaretskii @ 2018-03-27 18:46 ` Stefan Monnier 2018-03-27 19:27 ` Stefan Monnier 0 siblings, 1 reply; 17+ messages in thread From: Stefan Monnier @ 2018-03-27 18:46 UTC (permalink / raw) To: 30955; +Cc: Colin Baxter > To reproduce: > > emacs -Q > C-u C-h i /path/to/info/elisp.info RET > 2 > 3 > 4 > Click mouse-1 on the "Up: Programming Types" link on the header-line Hmm... I reduced it to src/emacs -Q --eval '(info "(elisp)Numbers")' Click mouse-1 on the "Up" link on the header-line and I fixed the "obvious" problem (see patch below), but now that just gives me: <header-line> <mouse-2> is undefined instead of <header-line> <header-line> <mouse-2> is undefined So now the event-rewrite gives the expected result (i.e. "<header-line> <mouse-2>"), but for some reason it decides it's unbound even tho it clearly is. IOW it seems to be looking in the wrong keymap(s). Stefan "not looking forward to debug sessions in read_key_sequence" diff --git a/lisp/mouse.el b/lisp/mouse.el index 6a98ee7353..fe8b76e953 100644 --- a/lisp/mouse.el +++ b/lisp/mouse.el @@ -135,7 +137,12 @@ mouse--click-1-maybe-follows-link (unless (get newup 'event-kind) (put newup 'event-kind (get (car last-input-event) 'event-kind))) - (vector (cons newup (cdr last-input-event))))))))) + ;; Modify the event in-place, otherwise we can get a prefix + ;; added again, so a click on the header-line turns + ;; into a [header-line header-line mouse-2] :-(. + ;; See fake_prefixed_keys in src/keyboard.c's. + (setf (car last-input-event) newup) + (vector last-input-event))))))) (define-key key-translation-map [down-mouse-1] #'mouse--down-1-maybe-follows-link) ^ permalink raw reply related [flat|nested] 17+ messages in thread
* bug#30955: 27.0.50; Mouse clicks on header-line in Info are broken 2018-03-27 18:46 ` Stefan Monnier @ 2018-03-27 19:27 ` Stefan Monnier 2018-03-28 6:07 ` Colin Baxter 2018-03-29 11:00 ` Eli Zaretskii 0 siblings, 2 replies; 17+ messages in thread From: Stefan Monnier @ 2018-03-27 19:27 UTC (permalink / raw) To: 30955-done; +Cc: Colin Baxter > Stefan "not looking forward to debug sessions in read_key_sequence" Ha, I found the sucker! Installed, Stefan --- a/src/keyboard.c +++ b/src/keyboard.c @@ -8701,10 +8701,19 @@ follow_key (Lisp_Object keymap, Lisp_Object key) } static Lisp_Object -active_maps (Lisp_Object first_event) +active_maps (Lisp_Object first_event, Lisp_Object second_event) { Lisp_Object position - = CONSP (first_event) ? CAR_SAFE (XCDR (first_event)) : Qnil; + = EVENT_HAS_PARAMETERS (first_event) ? EVENT_START (first_event) : Qnil; + /* The position of a click can be in the second event if the first event + is a pseudo-event like `header-line` or `mode-line`. */ + if (SYMBOLP (first_event) + && EVENT_HAS_PARAMETERS (second_event) + && EQ (first_event, POSN_POSN (EVENT_START (second_event)))) + { + eassert (NILP (position)); + position = EVENT_START (second_event); + } return Fcons (Qkeymap, Fcurrent_active_maps (Qt, position)); } @@ -9016,13 +9025,14 @@ read_key_sequence (Lisp_Object *keybuf, int bufsize, Lisp_Object prompt, starting_buffer = current_buffer; first_unbound = bufsize + 1; Lisp_Object first_event = mock_input > 0 ? keybuf[0] : Qnil; + Lisp_Object second_event = mock_input > 1 ? keybuf[1] : Qnil; /* Build our list of keymaps. If we recognize a function key and replace its escape sequence in keybuf with its symbol, or if the sequence starts with a mouse click and we need to switch buffers, we jump back here to rebuild the initial keymaps from the current buffer. */ - current_binding = active_maps (first_event); + current_binding = active_maps (first_event, second_event); /* Start from the beginning in keybuf. */ t = 0; @@ -9282,7 +9292,7 @@ read_key_sequence (Lisp_Object *keybuf, int bufsize, Lisp_Object prompt, && (XBUFFER (XWINDOW (selected_window)->contents) != current_buffer)) Fset_buffer (XWINDOW (selected_window)->contents); - current_binding = active_maps (first_event); + current_binding = active_maps (first_event, Qnil); } GROW_RAW_KEYBUF; ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#30955: 27.0.50; Mouse clicks on header-line in Info are broken 2018-03-27 19:27 ` Stefan Monnier @ 2018-03-28 6:07 ` Colin Baxter 2018-03-29 11:00 ` Eli Zaretskii 1 sibling, 0 replies; 17+ messages in thread From: Colin Baxter @ 2018-03-28 6:07 UTC (permalink / raw) To: 30955; +Cc: monnier >>>>> Stefan Monnier <monnier@IRO.UMontreal.CA> writes: >> Stefan "not looking forward to debug sessions in >> read_key_sequence" > Ha, I found the sucker! Installed, > Stefan > --- a/src/keyboard.c +++ b/src/keyboard.c @@ -8701,10 +8701,19 @@ > follow_key (Lisp_Object keymap, Lisp_Object key) } > static Lisp_Object -active_maps (Lisp_Object first_event) > +active_maps (Lisp_Object first_event, Lisp_Object second_event) { > Lisp_Object position - = CONSP (first_event) ? CAR_SAFE (XCDR > (first_event)) : Qnil; + = EVENT_HAS_PARAMETERS (first_event) ? > EVENT_START (first_event) : Qnil; + /* The position of a click can > be in the second event if the first event + is a pseudo-event like > `header-line` or `mode-line`. */ + if (SYMBOLP (first_event) + && > EVENT_HAS_PARAMETERS (second_event) + && EQ (first_event, > POSN_POSN (EVENT_START (second_event)))) + { + eassert (NILP > (position)); + position = EVENT_START (second_event); + } return > Fcons (Qkeymap, Fcurrent_active_maps (Qt, position)); } > @@ -9016,13 +9025,14 @@ read_key_sequence (Lisp_Object *keybuf, > int bufsize, Lisp_Object prompt, starting_buffer = current_buffer; > first_unbound = bufsize + 1; Lisp_Object first_event = mock_input > > 0 ? keybuf[0] : Qnil; + Lisp_Object second_event = mock_input > > 1 ? keybuf[1] : Qnil; > /* Build our list of keymaps. If we recognize a function key > and replace its escape sequence in keybuf with its symbol, or if > the sequence starts with a mouse click and we need to switch > buffers, we jump back here to rebuild the initial keymaps from the > current buffer. */ - current_binding = active_maps (first_event); > + current_binding = active_maps (first_event, second_event); > /* Start from the beginning in keybuf. */ t = 0; @@ -9282,7 > +9292,7 @@ read_key_sequence (Lisp_Object *keybuf, int bufsize, > Lisp_Object prompt, && (XBUFFER (XWINDOW > (selected_window)->contents) != current_buffer)) Fset_buffer > (XWINDOW (selected_window)->contents); - current_binding = > active_maps (first_event); + current_binding = active_maps > (first_event, Qnil); } > GROW_RAW_KEYBUF; Yes, that's fixed the issue for me - mouse now works normally. Thank you. Best wishes, Colin. ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#30955: 27.0.50; Mouse clicks on header-line in Info are broken 2018-03-27 19:27 ` Stefan Monnier 2018-03-28 6:07 ` Colin Baxter @ 2018-03-29 11:00 ` Eli Zaretskii 2018-03-29 12:10 ` Stefan Monnier 1 sibling, 1 reply; 17+ messages in thread From: Eli Zaretskii @ 2018-03-29 11:00 UTC (permalink / raw) To: Stefan Monnier; +Cc: m43cap, 30955 > From: Stefan Monnier <monnier@IRO.UMontreal.CA> > Cc: Eli Zaretskii <eliz@gnu.org>, Colin Baxter <m43cap@yandex.com> > Date: Tue, 27 Mar 2018 15:27:10 -0400 > > > Stefan "not looking forward to debug sessions in read_key_sequence" > > Ha, I found the sucker! > Installed, Thanks. The original bug is fixed, but I still don't understand something related. If I do "C-h c" and click mouse-1 on the Up link on the header-line, I see this in the echo area: <header-line> <down-mouse-1> (translated from <down-mouse-1>) at that spot runs the command mouse-drag-header-line <header-line> <mouse-2> (translated from <mouse-2>) at that spot runs the command Info-mouse-follow-link Why does the second line talk about mouse-2? I didn't click that button. I'd expect to see only mouse-1 mentioned in both lines. What am I missing? ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#30955: 27.0.50; Mouse clicks on header-line in Info are broken 2018-03-29 11:00 ` Eli Zaretskii @ 2018-03-29 12:10 ` Stefan Monnier 2018-03-29 12:24 ` Eli Zaretskii 0 siblings, 1 reply; 17+ messages in thread From: Stefan Monnier @ 2018-03-29 12:10 UTC (permalink / raw) To: Eli Zaretskii; +Cc: m43cap, 30955 >> > Stefan "not looking forward to debug sessions in read_key_sequence" >> Ha, I found the sucker! >> Installed, > Thanks. The original bug is fixed, but I still don't understand > something related. If I do "C-h c" and click mouse-1 on the Up link > on the header-line, I see this in the echo area: > > <header-line> <down-mouse-1> (translated from <down-mouse-1>) at that spot > runs the command mouse-drag-header-line > <header-line> <mouse-2> (translated from <mouse-2>) at that spot runs the > command Info-mouse-follow-link > > Why does the second line talk about mouse-2? I didn't click that > button. I'd expect to see only mouse-1 mentioned in both lines. To figure out what that click would run (Info-mouse-follow-link in this case), we have to perform the same translation as if you actually performed the action. There's indeed a bug, here, which is that it says (translated from <mouse-2>) instead of (translated from <mouse-1>) I assume it's because the fix I installed modifies the event in-place, so the recording of "untranslated events" gets changed by side-effect. Maybe we should record *copies* of events in there, to avoid this? Stefan ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#30955: 27.0.50; Mouse clicks on header-line in Info are broken 2018-03-29 12:10 ` Stefan Monnier @ 2018-03-29 12:24 ` Eli Zaretskii 2018-03-29 13:11 ` Stefan Monnier 0 siblings, 1 reply; 17+ messages in thread From: Eli Zaretskii @ 2018-03-29 12:24 UTC (permalink / raw) To: Stefan Monnier; +Cc: m43cap, 30955 > From: Stefan Monnier <monnier@IRO.UMontreal.CA> > Cc: 30955@debbugs.gnu.org, m43cap@yandex.com > Date: Thu, 29 Mar 2018 08:10:03 -0400 > > There's indeed a bug, here, which is that it says > > (translated from <mouse-2>) > > instead of > > (translated from <mouse-1>) > > I assume it's because the fix I installed modifies the event in-place, > so the recording of "untranslated events" gets changed by side-effect. I don't think so: I saw the mouse-2 part even before you fixed the problem. So I think it's something else at work. ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#30955: 27.0.50; Mouse clicks on header-line in Info are broken 2018-03-29 12:24 ` Eli Zaretskii @ 2018-03-29 13:11 ` Stefan Monnier 2018-03-29 13:30 ` Colin Baxter 2018-03-31 17:18 ` Eli Zaretskii 0 siblings, 2 replies; 17+ messages in thread From: Stefan Monnier @ 2018-03-29 13:11 UTC (permalink / raw) To: Eli Zaretskii; +Cc: m43cap, 30955 Eli Zaretskii <eliz@gnu.org> writes: >> From: Stefan Monnier <monnier@IRO.UMontreal.CA> >> Cc: 30955@debbugs.gnu.org, m43cap@yandex.com >> Date: Thu, 29 Mar 2018 08:10:03 -0400 >> >> There's indeed a bug, here, which is that it says >> >> (translated from <mouse-2>) >> >> instead of >> >> (translated from <mouse-1>) >> >> I assume it's because the fix I installed modifies the event in-place, >> so the recording of "untranslated events" gets changed by side-effect. > > I don't think so: I saw the mouse-2 part even before you fixed the > problem. Maybe you've seen it with yet-older code, such as the one in the emacs-26 branch (in that code, the mouse-1 => mouse-2 remapping was done elsewhere (i.e. as part of the processing of down-mouse-1) so read_key_sequence never even saw the mouse-1 event to put it into the raw_keybuf)? > So I think it's something else at work. Yet the second hunk below does fix this problem (the first hunk fixes the same problem but for C-h l, and the third just removes code which does something wrong, and I have no idea why the code was there in the first place). Stefan diff --git a/src/keyboard.c b/src/keyboard.c index 044e3fac69..6380e8585f 100644 --- a/src/keyboard.c +++ b/src/keyboard.c @@ -3258,7 +3258,10 @@ record_char (Lisp_Object c) if (!recorded) { total_keys += total_keys < NUM_RECENT_KEYS; - ASET (recent_keys, recent_keys_index, c); + ASET (recent_keys, recent_keys_index, + /* Copy the event, in case it gets modified by side-effect + by some remapping function. */ + CONSP (c) ? Fcopy_sequence (c) : c); if (++recent_keys_index >= NUM_RECENT_KEYS) recent_keys_index = 0; } @@ -9296,7 +9299,10 @@ read_key_sequence (Lisp_Object *keybuf, int bufsize, Lisp_Object prompt, } GROW_RAW_KEYBUF; - ASET (raw_keybuf, raw_keybuf_count, key); + ASET (raw_keybuf, raw_keybuf_count, + /* Copy the event, in case it gets modified by side-effect + by some remapping function. */ + CONSP (key) ? Fcopy_sequence (key) : key); raw_keybuf_count++; } @@ -9343,9 +9349,6 @@ read_key_sequence (Lisp_Object *keybuf, int bufsize, Lisp_Object prompt, && BUFFERP (XWINDOW (window)->contents) && XBUFFER (XWINDOW (window)->contents) != current_buffer) { - GROW_RAW_KEYBUF; - ASET (raw_keybuf, raw_keybuf_count, key); - raw_keybuf_count++; keybuf[t] = key; mock_input = t + 1; ^ permalink raw reply related [flat|nested] 17+ messages in thread
* bug#30955: 27.0.50; Mouse clicks on header-line in Info are broken 2018-03-29 13:11 ` Stefan Monnier @ 2018-03-29 13:30 ` Colin Baxter 2018-03-31 17:18 ` Eli Zaretskii 1 sibling, 0 replies; 17+ messages in thread From: Colin Baxter @ 2018-03-29 13:30 UTC (permalink / raw) To: Stefan Monnier; +Cc: 30955 >>>>> Stefan Monnier <monnier@IRO.UMontreal.CA> writes: > Eli Zaretskii <eliz@gnu.org> writes: >>> From: Stefan Monnier <monnier@IRO.UMontreal.CA> Cc: >>> 30955@debbugs.gnu.org, m43cap@yandex.com Date: Thu, 29 Mar 2018 >>> 08:10:03 -0400 >>> >>> There's indeed a bug, here, which is that it says >>> >>> (translated from <mouse-2>) >>> >>> instead of >>> >>> (translated from <mouse-1>) >>> >>> I assume it's because the fix I installed modifies the event >>> in-place, so the recording of "untranslated events" gets changed >>> by side-effect. >> >> I don't think so: I saw the mouse-2 part even before you fixed >> the problem. > Maybe you've seen it with yet-older code, such as the one in the > emacs-26 branch (in that code, the mouse-1 => mouse-2 remapping > was done elsewhere (i.e. as part of the processing of > down-mouse-1) so read_key_sequence never even saw the mouse-1 > event to put it into the raw_keybuf)? >> So I think it's something else at work. > Yet the second hunk below does fix this problem (the first hunk > fixes the same problem but for C-h l, and the third just removes > code which does something wrong, and I have no idea why the code > was there in the first place). This may not be relevant, but I've noticed that this mouse problem https://lists.gnu.org/archive/html/emacs-devel/2016-04/msg00499.html is now no longer present. I remember I didn't follow the suggestion in the thread to bisect, so I'm unaware when it was fixed. I don't have the problem now so perhaps Stephan's patch fixed that too. Best wishes, ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#30955: 27.0.50; Mouse clicks on header-line in Info are broken 2018-03-29 13:11 ` Stefan Monnier 2018-03-29 13:30 ` Colin Baxter @ 2018-03-31 17:18 ` Eli Zaretskii 2018-03-31 18:56 ` Colin Baxter 2018-03-31 23:40 ` Stefan Monnier 1 sibling, 2 replies; 17+ messages in thread From: Eli Zaretskii @ 2018-03-31 17:18 UTC (permalink / raw) To: Stefan Monnier; +Cc: m43cap, 30955 > From: Stefan Monnier <monnier@IRO.UMontreal.CA> > Cc: 30955@debbugs.gnu.org, m43cap@yandex.com > Date: Thu, 29 Mar 2018 09:11:41 -0400 > > >> There's indeed a bug, here, which is that it says > >> > >> (translated from <mouse-2>) > >> > >> instead of > >> > >> (translated from <mouse-1>) > >> > >> I assume it's because the fix I installed modifies the event in-place, > >> so the recording of "untranslated events" gets changed by side-effect. > > > > I don't think so: I saw the mouse-2 part even before you fixed the > > problem. > > Maybe you've seen it with yet-older code, such as the one in the > emacs-26 branch (in that code, the mouse-1 => mouse-2 remapping was done > elsewhere (i.e. as part of the processing of down-mouse-1) so > read_key_sequence never even saw the mouse-1 event to put it into the > raw_keybuf)? > > > So I think it's something else at work. > > Yet the second hunk below does fix this problem (the first hunk fixes > the same problem but for C-h l, and the third just removes code which > does something wrong, and I have no idea why the code was there in the > first place). AFAICT, this patch is now installed on master, but I still see the same issue: "C-h c" reports mouse-2 whereas I click mouse-1. Was this issue supposed to be resolved, and if so, what am I missing? ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#30955: 27.0.50; Mouse clicks on header-line in Info are broken 2018-03-31 17:18 ` Eli Zaretskii @ 2018-03-31 18:56 ` Colin Baxter 2018-03-31 19:03 ` Eli Zaretskii 2018-03-31 23:40 ` Stefan Monnier 1 sibling, 1 reply; 17+ messages in thread From: Colin Baxter @ 2018-03-31 18:56 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 30955, Stefan Monnier >>>>> Eli Zaretskii <eliz@gnu.org> writes: >> From: Stefan Monnier <monnier@IRO.UMontreal.CA> Cc: >> 30955@debbugs.gnu.org, m43cap@yandex.com Date: Thu, 29 Mar 2018 >> 09:11:41 -0400 >> >> >> There's indeed a bug, here, which is that it says >> >> >> >> (translated from <mouse-2>) >> >> >> >> instead of >> >> >> >> (translated from <mouse-1>) >> >> >> >> I assume it's because the fix I installed modifies the event >> in-place, >> so the recording of "untranslated events" gets >> changed by side-effect. >> > >> > I don't think so: I saw the mouse-2 part even before you fixed >> the > problem. >> >> Maybe you've seen it with yet-older code, such as the one in the >> emacs-26 branch (in that code, the mouse-1 => mouse-2 remapping >> was done elsewhere (i.e. as part of the processing of >> down-mouse-1) so read_key_sequence never even saw the mouse-1 >> event to put it into the raw_keybuf)? >> >> > So I think it's something else at work. >> >> Yet the second hunk below does fix this problem (the first hunk >> fixes the same problem but for C-h l, and the third just removes >> code which does something wrong, and I have no idea why the code >> was there in the first place). > AFAICT, this patch is now installed on master, but I still see the > same issue: "C-h c" reports mouse-2 whereas I click mouse-1. Was > this issue supposed to be resolved, and if so, what am I missing? For me, C-h c gives mouse-1 for the left-hand button (mouse 1) and mouse-3 for the right-hand button (mouse 3). Best wishes, Colin. ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#30955: 27.0.50; Mouse clicks on header-line in Info are broken 2018-03-31 18:56 ` Colin Baxter @ 2018-03-31 19:03 ` Eli Zaretskii 2018-03-31 19:16 ` Eli Zaretskii 2018-03-31 20:55 ` Colin Baxter 0 siblings, 2 replies; 17+ messages in thread From: Eli Zaretskii @ 2018-03-31 19:03 UTC (permalink / raw) To: Colin Baxter; +Cc: 30955, monnier > From: Colin Baxter <m43cap@yandex.com> > Cc: Stefan Monnier <monnier@IRO.UMontreal.CA>, 30955@debbugs.gnu.org > Cc: > Date: Sat, 31 Mar 2018 19:56:30 +0100 > > > AFAICT, this patch is now installed on master, but I still see the > > same issue: "C-h c" reports mouse-2 whereas I click mouse-1. Was > > this issue supposed to be resolved, and if so, what am I missing? > > For me, C-h c gives mouse-1 for the left-hand button (mouse 1) and > mouse-3 for the right-hand button (mouse 3). Maybe it's a Windows-specific issue, then. But just to be sure: can you describe the exact sequence of steps you are taking, starting from "emacs -Q"? In particular, are you clicking on the Next/Prev/Up links of the header-line in an Info buffer? ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#30955: 27.0.50; Mouse clicks on header-line in Info are broken 2018-03-31 19:03 ` Eli Zaretskii @ 2018-03-31 19:16 ` Eli Zaretskii 2018-03-31 20:59 ` Colin Baxter 2018-03-31 20:55 ` Colin Baxter 1 sibling, 1 reply; 17+ messages in thread From: Eli Zaretskii @ 2018-03-31 19:16 UTC (permalink / raw) To: monnier; +Cc: m43cap, 30955 > Date: Sat, 31 Mar 2018 22:03:46 +0300 > From: Eli Zaretskii <eliz@gnu.org> > Cc: 30955@debbugs.gnu.org, monnier@IRO.UMontreal.CA > > But just to be sure: can you describe the exact sequence of steps you > are taking, starting from "emacs -Q"? In particular, are you clicking > on the Next/Prev/Up links of the header-line in an Info buffer? Btw, the keymap property we put on the header-line does bind mouse-2 to a command that follows link, not mouse-1: (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-2] 'Info-mouse-follow-link) (define-key keymap [mouse-2] 'Info-mouse-follow-link) (define-key keymap [follow-link] 'mouse-face) So I guess this is somehow related to the processing of mouse-1-click-follows-link. ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#30955: 27.0.50; Mouse clicks on header-line in Info are broken 2018-03-31 19:16 ` Eli Zaretskii @ 2018-03-31 20:59 ` Colin Baxter 0 siblings, 0 replies; 17+ messages in thread From: Colin Baxter @ 2018-03-31 20:59 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 30955, monnier >>>>> Eli Zaretskii <eliz@gnu.org> writes: >> Date: Sat, 31 Mar 2018 22:03:46 +0300 From: Eli Zaretskii >> <eliz@gnu.org> Cc: 30955@debbugs.gnu.org, >> monnier@IRO.UMontreal.CA >> >> But just to be sure: can you describe the exact sequence of steps >> you are taking, starting from "emacs -Q"? In particular, are you >> clicking on the Next/Prev/Up links of the header-line in an Info >> buffer? > Btw, the keymap property we put on the header-line does bind > mouse-2 to a command that follows link, not mouse-1: > (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-2] > 'Info-mouse-follow-link) (define-key keymap [mouse-2] > 'Info-mouse-follow-link) (define-key keymap [follow-link] > 'mouse-face) > So I guess this is somehow related to the processing of > mouse-1-click-follows-link. As an ordinary user, my keyboard inputs don't produce any obvious reference to mouse-2. ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#30955: 27.0.50; Mouse clicks on header-line in Info are broken 2018-03-31 19:03 ` Eli Zaretskii 2018-03-31 19:16 ` Eli Zaretskii @ 2018-03-31 20:55 ` Colin Baxter 1 sibling, 0 replies; 17+ messages in thread From: Colin Baxter @ 2018-03-31 20:55 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 30955, monnier >>>>> Eli Zaretskii <eliz@gnu.org> writes: >> From: Colin Baxter <m43cap@yandex.com> Cc: Stefan Monnier >> <monnier@IRO.UMontreal.CA>, 30955@debbugs.gnu.org Cc: Date: Sat, >> 31 Mar 2018 19:56:30 +0100 >> >> > AFAICT, this patch is now installed on master, but I still see >> the > same issue: "C-h c" reports mouse-2 whereas I click >> mouse-1. Was > this issue supposed to be resolved, and if so, >> what am I missing? >> >> For me, C-h c gives mouse-1 for the left-hand button (mouse 1) >> and mouse-3 for the right-hand button (mouse 3). > Maybe it's a Windows-specific issue, then. > But just to be sure: can you describe the exact sequence of steps > you are taking, starting from "emacs -Q"? In particular, are you > clicking on the Next/Prev/Up links of the header-line in an Info > buffer? 1. src/emacs -Q 2. M-x info 3. Click "emacs", for example, with left button (mouse-1). 4. Click Up: (dir) with left button (mouse-1) takes me back to Info Directory. 5. Click "Emacs Lisp Intro:", as another example, with left button (mouse-1) 6. Navigate down and up (clicking Prev: or Up:), all with mouse-1. Hope this helps. ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#30955: 27.0.50; Mouse clicks on header-line in Info are broken 2018-03-31 17:18 ` Eli Zaretskii 2018-03-31 18:56 ` Colin Baxter @ 2018-03-31 23:40 ` Stefan Monnier 2018-04-01 6:50 ` Eli Zaretskii 1 sibling, 1 reply; 17+ messages in thread From: Stefan Monnier @ 2018-03-31 23:40 UTC (permalink / raw) To: Eli Zaretskii; +Cc: m43cap, 30955 > AFAICT, this patch is now installed on master, but I still see the > same issue: "C-h c" reports mouse-2 whereas I click mouse-1. It should report "header-line mouse-2 (translated from mouse-1)", yes. Stefan ^ permalink raw reply [flat|nested] 17+ messages in thread
* bug#30955: 27.0.50; Mouse clicks on header-line in Info are broken 2018-03-31 23:40 ` Stefan Monnier @ 2018-04-01 6:50 ` Eli Zaretskii 0 siblings, 0 replies; 17+ messages in thread From: Eli Zaretskii @ 2018-04-01 6:50 UTC (permalink / raw) To: Stefan Monnier; +Cc: m43cap, 30955 > From: Stefan Monnier <monnier@IRO.UMontreal.CA> > Cc: 30955@debbugs.gnu.org, m43cap@yandex.com > Date: Sat, 31 Mar 2018 19:40:29 -0400 > > > AFAICT, this patch is now installed on master, but I still see the > > same issue: "C-h c" reports mouse-2 whereas I click mouse-1. > > It should report "header-line mouse-2 (translated from mouse-1)", yes. OK, thanks. ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2018-04-01 6:50 UTC | newest] Thread overview: 17+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2018-03-26 14:54 bug#30955: 27.0.50; Mouse clicks on header-line in Info are broken Eli Zaretskii 2018-03-27 18:46 ` Stefan Monnier 2018-03-27 19:27 ` Stefan Monnier 2018-03-28 6:07 ` Colin Baxter 2018-03-29 11:00 ` Eli Zaretskii 2018-03-29 12:10 ` Stefan Monnier 2018-03-29 12:24 ` Eli Zaretskii 2018-03-29 13:11 ` Stefan Monnier 2018-03-29 13:30 ` Colin Baxter 2018-03-31 17:18 ` Eli Zaretskii 2018-03-31 18:56 ` Colin Baxter 2018-03-31 19:03 ` Eli Zaretskii 2018-03-31 19:16 ` Eli Zaretskii 2018-03-31 20:59 ` Colin Baxter 2018-03-31 20:55 ` Colin Baxter 2018-03-31 23:40 ` Stefan Monnier 2018-04-01 6:50 ` Eli Zaretskii
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).