bug#30955: 27.0.50; Mouse clicks on header-line in Info are broken

bug#30955: 27.0.50; Mouse clicks on header-line in Info are broken

[Eli Zaretskii]

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

bug#30955: 27.0.50; Mouse clicks on header-line in Info are broken

[Stefan Monnier]

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

bug#30955: 27.0.50; Mouse clicks on header-line in Info are broken

[Stefan Monnier]

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

bug#30955: 27.0.50; Mouse clicks on header-line in Info are broken

[Colin Baxter]

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

bug#30955: 27.0.50; Mouse clicks on header-line in Info are broken

[Eli Zaretskii]

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

bug#30955: 27.0.50; Mouse clicks on header-line in Info are broken

[Stefan Monnier]

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

bug#30955: 27.0.50; Mouse clicks on header-line in Info are broken

[Eli Zaretskii]

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

bug#30955: 27.0.50; Mouse clicks on header-line in Info are broken

[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 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;
 

bug#30955: 27.0.50; Mouse clicks on header-line in Info are broken

[Colin Baxter]

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

bug#30955: 27.0.50; Mouse clicks on header-line in Info are broken

[Eli Zaretskii]

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

bug#30955: 27.0.50; Mouse clicks on header-line in Info are broken

[Colin Baxter]

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

bug#30955: 27.0.50; Mouse clicks on header-line in Info are broken

[Eli Zaretskii]

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

bug#30955: 27.0.50; Mouse clicks on header-line in Info are broken

[Eli Zaretskii]

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

bug#30955: 27.0.50; Mouse clicks on header-line in Info are broken

[Colin Baxter]

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

bug#30955: 27.0.50; Mouse clicks on header-line in Info are broken

[Colin Baxter]

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

bug#30955: 27.0.50; Mouse clicks on header-line in Info are broken

[Stefan Monnier]

> 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

bug#30955: 27.0.50; Mouse clicks on header-line in Info are broken

[Eli Zaretskii]

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