GNU bug report logs - #76620
30.1.50; mouse-1 mode-line bindings are unusable when point is on a button

Previous Next

To reply to this bug, email your comments to 76620 AT debbugs.gnu.org.
There is no need to reopen the bug first.

Toggle the display of automated, internal messages from the tracker.

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

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.1.50; mouse-1 mode-line bindings are unusable when point is on a
 button
Date: Thu, 27 Feb 2025 18:11:36 -0500

1. emacs -Q
2. Position point over a button.el button, e.g.
   (progn (view-emacs-news) (forward-button 1))
3. mouse-2 anywhere on the mode line.
4. Note that instead of the usual mouse-delete-other-windows binding,
   the button at point is activated.

This is because the local keymap for buttons is button-map, which binds
"<mode-line> <mouse-2>".  This is confusing, and probably a bug, but not
too bad of a bug.

Substantially worse is this:

5. mouse-1 on a part of the mode-line with a mouse-1 binding; for
   example, mouse-1 on the buffer coding system indicator "U" at the
   start of the mode line.

6. Instead of describing the buffer's coding system, the button at point
   is activated.

This is because mouse-1-click-follows-link translates the mouse-1 into a
mouse-2.  This makes all mouse-1 bindings on the mode line basically
broken while point is on a button.

The mode-line (and header-line) binding was added to button.el in
24fc9480399b2d018e8d85f34e9c5d8c327ce3bf to support using buttons in the
mode-line and header-line.  I suggest that we should remove those
bindings, in favor of some other way to use button.el in the mode-line
or header-line.  Especially because, from grepping through ~400 popular
packages (the ones installed at my site), I see no usage of buttons in
the mode-line or header-line.


In GNU Emacs 30.1.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo
 version 1.15.12, Xaw scroll bars) of 2025-02-24 built on
 igm-qws-u22796a
Repository revision: b3f0c1a30a1fee5a81b7a0c6c7f52ec0ef5bade6
Repository branch: emacs-30
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Rocky Linux 8.10 (Green Obsidian)

Configured using:
 'configure --config-cache --with-x-toolkit=lucid --without-gpm
 --without-gconf --without-selinux --without-imagemagick --with-modules
 --with-gif=no --with-cairo --with-rsvg --without-compress-install
 --with-tree-sitter'

Configured features:
CAIRO DBUS FREETYPE GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG LIBSYSTEMD
LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP
SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER X11 XDBE XIM
XINPUT2 XPM LUCID ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  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
  minibuffer-regexp-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr compile comint ansi-osc ansi-color ring comp-run
bytecomp byte-compile comp-common rx emacsbug message mailcap yank-media
puny dired dired-loaddefs rfc822 mml mml-sec password-cache epa derived
epg rfc6068 epg-config gnus-util text-property-search time-date subr-x
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 rmc iso-transl tooltip cconv eldoc paren
electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/x-win x-win term/common-win x-dnd touch-screen 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 nadvice seq simple cl-generic
indonesian philippine 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 abbrev obarray oclosure cl-preloaded button loaddefs
theme-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 dbusbind inotify
dynamic-setting system-font-setting font-render-setting cairo x-toolkit
xinput2 x multi-tty move-toolbar make-network-process native-compile
emacs)

Memory information:
((conses 16 92421 9053) (symbols 48 6739 0) (strings 32 26097 2919)
 (string-bytes 1 786157) (vectors 16 16424)
 (vector-slots 8 188776 8192) (floats 8 37 1) (intervals 56 320 0)
 (buffers 992 11))

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Spencer Baugh <sbaugh <at> janestreet.com>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 76620 <at> debbugs.gnu.org, jonas <at> bernoul.li
Subject: Re: bug#76620: 30.1.50;
 mouse-1 mode-line bindings are unusable when point is on a button
Date: Fri, 28 Feb 2025 09:52:10 +0200

> Cc: Jonas Bernoulli <jonas <at> bernoul.li>
> Date: Thu, 27 Feb 2025 18:11:36 -0500
> From:  Spencer Baugh via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> 
> 1. emacs -Q
> 2. Position point over a button.el button, e.g.
>    (progn (view-emacs-news) (forward-button 1))
> 3. mouse-2 anywhere on the mode line.
> 4. Note that instead of the usual mouse-delete-other-windows binding,
>    the button at point is activated.
> 
> This is because the local keymap for buttons is button-map, which binds
> "<mode-line> <mouse-2>".  This is confusing, and probably a bug, but not
> too bad of a bug.
> 
> Substantially worse is this:
> 
> 5. mouse-1 on a part of the mode-line with a mouse-1 binding; for
>    example, mouse-1 on the buffer coding system indicator "U" at the
>    start of the mode line.
> 
> 6. Instead of describing the buffer's coding system, the button at point
>    is activated.
> 
> This is because mouse-1-click-follows-link translates the mouse-1 into a
> mouse-2.  This makes all mouse-1 bindings on the mode line basically
> broken while point is on a button.

The bugs with mouse-1 are solved on the master branch (see bug#75219).
So I can reproduce the last two items in Emacs 30, but not in Emacs
31.  The problems with mouse-2 are still present on the master branch.

> The mode-line (and header-line) binding was added to button.el in
> 24fc9480399b2d018e8d85f34e9c5d8c327ce3bf to support using buttons in the
> mode-line and header-line.  I suggest that we should remove those
> bindings, in favor of some other way to use button.el in the mode-line
> or header-line.  Especially because, from grepping through ~400 popular
> packages (the ones installed at my site), I see no usage of buttons in
> the mode-line or header-line.

Adding Stefan to the discussion.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: sbaugh <at> janestreet.com, monnier <at> iro.umontreal.ca
Cc: 76620 <at> debbugs.gnu.org, jonas <at> bernoul.li
Subject: Re: bug#76620: 30.1.50;
 mouse-1 mode-line bindings are unusable when point is on a button
Date: Fri, 28 Feb 2025 10:27:04 +0200

> Cc: 76620 <at> debbugs.gnu.org, jonas <at> bernoul.li
> Date: Fri, 28 Feb 2025 09:52:10 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> > 5. mouse-1 on a part of the mode-line with a mouse-1 binding; for
> >    example, mouse-1 on the buffer coding system indicator "U" at the
> >    start of the mode line.
> > 
> > 6. Instead of describing the buffer's coding system, the button at point
> >    is activated.
> > 
> > This is because mouse-1-click-follows-link translates the mouse-1 into a
> > mouse-2.  This makes all mouse-1 bindings on the mode line basically
> > broken while point is on a button.
> 
> The bugs with mouse-1 are solved on the master branch (see bug#75219).
> So I can reproduce the last two items in Emacs 30, but not in Emacs
> 31.  The problems with mouse-2 are still present on the master branch.

I've now cherry-picked that fix to the emacs-30 branch, so the issues
with mouse-1 on the mode line in this situation should be solved in
Emacs 30.2.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Spencer Baugh <sbaugh <at> janestreet.com>, 76620 <at> debbugs.gnu.org,
 jonas <at> bernoul.li
Subject: Re: bug#76620: 30.1.50; mouse-1 mode-line bindings are unusable
 when point is on a button
Date: Fri, 28 Feb 2025 10:44:00 -0500

>> The mode-line (and header-line) binding was added to button.el in
>> 24fc9480399b2d018e8d85f34e9c5d8c327ce3bf to support using buttons in the
>> mode-line and header-line.  I suggest that we should remove those
>> bindings, in favor of some other way to use button.el in the mode-line
>> or header-line.  Especially because, from grepping through ~400 popular
>> packages (the ones installed at my site), I see no usage of buttons in
>> the mode-line or header-line.
>
> Adding Stefan to the discussion.

FWIW, I've used code which used the same text (with buttons) in
the header-line and in the buffer.  But yeah, that was more an
experiment than anything.  I don't think I still use such code.
So, it's a "nice to have" but not if it breaks something else.

[ In another similar experiment, I tried to make an "in-buffer
  toolbar", but for that one using the same data was simply not an
  option, I needed a translation function.  ]

Seeing some of the crazy things some people do in fancy packages,
I wouldn't be completely surprised to hear that some people actually use
such things rather than just experiment with them.


        Stefan

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: sbaugh <at> janestreet.com, 76620 <at> debbugs.gnu.org, jonas <at> bernoul.li
Subject: Re: bug#76620: 30.1.50; mouse-1 mode-line bindings are unusable
 when point is on a button
Date: Sun, 09 Mar 2025 11:50:20 +0200

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Spencer Baugh <sbaugh <at> janestreet.com>,  76620 <at> debbugs.gnu.org,
>   jonas <at> bernoul.li
> Date: Fri, 28 Feb 2025 10:44:00 -0500
> 
> >> The mode-line (and header-line) binding was added to button.el in
> >> 24fc9480399b2d018e8d85f34e9c5d8c327ce3bf to support using buttons in the
> >> mode-line and header-line.  I suggest that we should remove those
> >> bindings, in favor of some other way to use button.el in the mode-line
> >> or header-line.  Especially because, from grepping through ~400 popular
> >> packages (the ones installed at my site), I see no usage of buttons in
> >> the mode-line or header-line.
> >
> > Adding Stefan to the discussion.
> 
> FWIW, I've used code which used the same text (with buttons) in
> the header-line and in the buffer.  But yeah, that was more an
> experiment than anything.  I don't think I still use such code.
> So, it's a "nice to have" but not if it breaks something else.

So, on balance, you think we should revert commit
24fc9480399b2d018e8d85f34e9c5d8c327ce3bf?

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: sbaugh <at> janestreet.com, 76620 <at> debbugs.gnu.org, jonas <at> bernoul.li
Subject: Re: bug#76620: 30.1.50; mouse-1 mode-line bindings are unusable
 when point is on a button
Date: Sun, 09 Mar 2025 18:25:24 -0400

>> FWIW, I've used code which used the same text (with buttons) in
>> the header-line and in the buffer.  But yeah, that was more an
>> experiment than anything.  I don't think I still use such code.
>> So, it's a "nice to have" but not if it breaks something else.
>
> So, on balance, you think we should revert commit
> 24fc9480399b2d018e8d85f34e9c5d8c327ce3bf?

I haven't looked at the problem closely enough to have an opinion, sorry.


        Stefan

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

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 76620 <at> debbugs.gnu.org, jonas <at> bernoul.li,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#76620: 30.1.50; mouse-1 mode-line bindings are unusable
 when point is on a button
Date: Thu, 28 Aug 2025 14:22:32 -0400

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Cc: Jonas Bernoulli <jonas <at> bernoul.li>
>> Date: Thu, 27 Feb 2025 18:11:36 -0500
>> From:  Spencer Baugh via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>> 
>> 
>> 1. emacs -Q
>> 2. Position point over a button.el button, e.g.
>>    (progn (view-emacs-news) (forward-button 1))
>> 3. mouse-2 anywhere on the mode line.
>> 4. Note that instead of the usual mouse-delete-other-windows binding,
>>    the button at point is activated.
>> 
>> This is because the local keymap for buttons is button-map, which binds
>> "<mode-line> <mouse-2>".  This is confusing, and probably a bug, but not
>> too bad of a bug.
>> 
>> Substantially worse is this:
>> 
>> 5. mouse-1 on a part of the mode-line with a mouse-1 binding; for
>>    example, mouse-1 on the buffer coding system indicator "U" at the
>>    start of the mode line.
>> 
>> 6. Instead of describing the buffer's coding system, the button at point
>>    is activated.
>> 
>> This is because mouse-1-click-follows-link translates the mouse-1 into a
>> mouse-2.  This makes all mouse-1 bindings on the mode line basically
>> broken while point is on a button.
>
> The bugs with mouse-1 are solved on the master branch (see bug#75219).
> So I can reproduce the last two items in Emacs 30, but not in Emacs
> 31.  The problems with mouse-2 are still present on the master branch.

The attached patch should fix the remaining bug, without dropping
support for button.el in the mode-line or header-line.

[0001-Always-ignore-keymaps-at-point-when-clicking-mode-an.patch (text/x-patch, inline)]

From 1ebb6e8822b5fc635549be14a3d4f2dd6f2d77a4 Mon Sep 17 00:00:00 2001
From: Spencer Baugh <sbaugh <at> janestreet.com>
Date: Thu, 28 Aug 2025 14:13:24 -0400
Subject: [PATCH] Always ignore keymaps at point when clicking mode and header
 line

In c41ea047a43, we started ignoring the keymap at point when a
position is a click on the mode line or header line.  However,
we only did this when POSN_STRING was non-nil, which isn't
always the case for clicks on the mode line and header line.
Move the check for mode line or header line outside the check
for non-nil POSN_STRING so it takes effect in that case.

* src/keymap.c (Fcurrent_active_maps): Ignore keymaps at point
for all clicks on mode and header line.  (bug#76620)
---
 src/keymap.c | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/src/keymap.c b/src/keymap.c
index 2c250578b00..263bf336a71 100644
--- a/src/keymap.c
+++ b/src/keymap.c
@@ -1735,6 +1735,16 @@ DEFUN ("current-active-maps", Fcurrent_active_maps, Scurrent_active_maps,
 		}
 	    }
 
+	  Lisp_Object pos_area = POSN_POSN (position);
+	  if (EQ (pos_area, Qmode_line) || EQ (pos_area, Qheader_line))
+	    {
+	      /* For clicks on mode line or header line, ignore the maps
+		 we found at POSITION, because properties at point are
+		 not relevant in that case.  */
+	      local_map = Qnil;
+	      keymap = Qnil;
+	    }
+
 	  /* If on a mode line string with a local keymap,
 	     or for a click on a string, i.e. overlay string or a
 	     string displayed via the `display' property,
@@ -1751,20 +1761,10 @@ DEFUN ("current-active-maps", Fcurrent_active_maps, Scurrent_active_maps,
 		{
 		  Lisp_Object map = Fget_text_property (pos, Qlocal_map,
 							string);
-		  Lisp_Object pos_area = POSN_POSN (position);
-		  /* For clicks on mode line or header line, override
-		     the maps we found at POSITION unconditionally, even
-		     if the corresponding properties of the mode- or
-		     header-line string are nil, because propertries at
-		     point are not relevant in that case.  */
-		  if (!NILP (map)
-		      || EQ (pos_area, Qmode_line)
-		      || EQ (pos_area, Qheader_line))
+		  if (!NILP (map))
 		    local_map = map;
 		  map = Fget_text_property (pos, Qkeymap, string);
-		  if (!NILP (map)
-		      || EQ (pos_area, Qmode_line)
-		      || EQ (pos_area, Qheader_line))
+		  if (!NILP (map))
 		    keymap = map;
 		}
 	    }
-- 
2.43.7

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: 76620 <at> debbugs.gnu.org, jonas <at> bernoul.li, monnier <at> iro.umontreal.ca
Subject: Re: bug#76620: 30.1.50; mouse-1 mode-line bindings are unusable
 when point is on a button
Date: Sat, 30 Aug 2025 13:55:18 +0300

> From: Spencer Baugh <sbaugh <at> janestreet.com>
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>,  76620 <at> debbugs.gnu.org,
>    jonas <at> bernoul.li
> Date: Thu, 28 Aug 2025 14:22:32 -0400
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> Cc: Jonas Bernoulli <jonas <at> bernoul.li>
> >> Date: Thu, 27 Feb 2025 18:11:36 -0500
> >> From:  Spencer Baugh via "Bug reports for GNU Emacs,
> >>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> >> 
> >> 
> >> 1. emacs -Q
> >> 2. Position point over a button.el button, e.g.
> >>    (progn (view-emacs-news) (forward-button 1))
> >> 3. mouse-2 anywhere on the mode line.
> >> 4. Note that instead of the usual mouse-delete-other-windows binding,
> >>    the button at point is activated.
> >> 
> >> This is because the local keymap for buttons is button-map, which binds
> >> "<mode-line> <mouse-2>".  This is confusing, and probably a bug, but not
> >> too bad of a bug.
> >> 
> >> Substantially worse is this:
> >> 
> >> 5. mouse-1 on a part of the mode-line with a mouse-1 binding; for
> >>    example, mouse-1 on the buffer coding system indicator "U" at the
> >>    start of the mode line.
> >> 
> >> 6. Instead of describing the buffer's coding system, the button at point
> >>    is activated.
> >> 
> >> This is because mouse-1-click-follows-link translates the mouse-1 into a
> >> mouse-2.  This makes all mouse-1 bindings on the mode line basically
> >> broken while point is on a button.
> >
> > The bugs with mouse-1 are solved on the master branch (see bug#75219).
> > So I can reproduce the last two items in Emacs 30, but not in Emacs
> > 31.  The problems with mouse-2 are still present on the master branch.
> 
> The attached patch should fix the remaining bug, without dropping
> support for button.el in the mode-line or header-line.
> 
> >From 1ebb6e8822b5fc635549be14a3d4f2dd6f2d77a4 Mon Sep 17 00:00:00 2001
> From: Spencer Baugh <sbaugh <at> janestreet.com>
> Date: Thu, 28 Aug 2025 14:13:24 -0400
> Subject: [PATCH] Always ignore keymaps at point when clicking mode and header
>  line
> 
> In c41ea047a43, we started ignoring the keymap at point when a
> position is a click on the mode line or header line.  However,
> we only did this when POSN_STRING was non-nil, which isn't
> always the case for clicks on the mode line and header line.
> Move the check for mode line or header line outside the check
> for non-nil POSN_STRING so it takes effect in that case.
> 
> * src/keymap.c (Fcurrent_active_maps): Ignore keymaps at point
> for all clicks on mode and header line.  (bug#76620)

I'm not sure I understand the logic of this change, so please
elaborate, by showing the form(s) of POSITION for which the current
code doesn't work, and please explain how this patch fixes that.

Thanks.

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

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 76620 <at> debbugs.gnu.org, jonas <at> bernoul.li, monnier <at> iro.umontreal.ca
Subject: Re: bug#76620: 30.1.50; mouse-1 mode-line bindings are unusable
 when point is on a button
Date: Sat, 30 Aug 2025 09:37:46 -0400

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Spencer Baugh <sbaugh <at> janestreet.com>
>> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>,  76620 <at> debbugs.gnu.org,
>>    jonas <at> bernoul.li
>> Date: Thu, 28 Aug 2025 14:22:32 -0400
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> >> Cc: Jonas Bernoulli <jonas <at> bernoul.li>
>> >> Date: Thu, 27 Feb 2025 18:11:36 -0500
>> >> From:  Spencer Baugh via "Bug reports for GNU Emacs,
>> >>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>> >> 
>> >> 
>> >> 1. emacs -Q
>> >> 2. Position point over a button.el button, e.g.
>> >>    (progn (view-emacs-news) (forward-button 1))
>> >> 3. mouse-2 anywhere on the mode line.
>> >> 4. Note that instead of the usual mouse-delete-other-windows binding,
>> >>    the button at point is activated.
>> >> 
>> >> This is because the local keymap for buttons is button-map, which binds
>> >> "<mode-line> <mouse-2>".  This is confusing, and probably a bug, but not
>> >> too bad of a bug.
>> >> 
>> >> Substantially worse is this:
>> >> 
>> >> 5. mouse-1 on a part of the mode-line with a mouse-1 binding; for
>> >>    example, mouse-1 on the buffer coding system indicator "U" at the
>> >>    start of the mode line.
>> >> 
>> >> 6. Instead of describing the buffer's coding system, the button at point
>> >>    is activated.
>> >> 
>> >> This is because mouse-1-click-follows-link translates the mouse-1 into a
>> >> mouse-2.  This makes all mouse-1 bindings on the mode line basically
>> >> broken while point is on a button.
>> >
>> > The bugs with mouse-1 are solved on the master branch (see bug#75219).
>> > So I can reproduce the last two items in Emacs 30, but not in Emacs
>> > 31.  The problems with mouse-2 are still present on the master branch.
>> 
>> The attached patch should fix the remaining bug, without dropping
>> support for button.el in the mode-line or header-line.
>> 
>> >From 1ebb6e8822b5fc635549be14a3d4f2dd6f2d77a4 Mon Sep 17 00:00:00 2001
>> From: Spencer Baugh <sbaugh <at> janestreet.com>
>> Date: Thu, 28 Aug 2025 14:13:24 -0400
>> Subject: [PATCH] Always ignore keymaps at point when clicking mode and header
>>  line
>> 
>> In c41ea047a43, we started ignoring the keymap at point when a
>> position is a click on the mode line or header line.  However,
>> we only did this when POSN_STRING was non-nil, which isn't
>> always the case for clicks on the mode line and header line.
>> Move the check for mode line or header line outside the check
>> for non-nil POSN_STRING so it takes effect in that case.
>> 
>> * src/keymap.c (Fcurrent_active_maps): Ignore keymaps at point
>> for all clicks on mode and header line.  (bug#76620)
>
> I'm not sure I understand the logic of this change, so please
> elaborate, by showing the form(s) of POSITION for which the current
> code doesn't work, and please explain how this patch fixes that.

When you click on a part of the mode line which is after the end of
mode-line-format, (at least on GNU/Linux) you get an event like this:

(down-mouse-1 (#<window 3 on *Bugs*> mode-line (2379 . 2071) 21536370
 nil nil (157 . 88) nil (8 . 19) (15 . 32)))

posn-string is nil for this but it's still in the mode-line.  My change
checks for whether a position is in the mode-line before checking if
posn-string is nil, so it catches such events.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: 76620 <at> debbugs.gnu.org, jonas <at> bernoul.li, monnier <at> iro.umontreal.ca
Subject: Re: bug#76620: 30.1.50; mouse-1 mode-line bindings are unusable
 when point is on a button
Date: Sat, 30 Aug 2025 16:50:52 +0300

> From: Spencer Baugh <sbaugh <at> janestreet.com>
> Cc: 76620 <at> debbugs.gnu.org,  jonas <at> bernoul.li,  monnier <at> iro.umontreal.ca
> Date: Sat, 30 Aug 2025 09:37:46 -0400
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> From: Spencer Baugh <sbaugh <at> janestreet.com>
> >> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>,  76620 <at> debbugs.gnu.org,
> >>    jonas <at> bernoul.li
> >> Date: Thu, 28 Aug 2025 14:22:32 -0400
> >> 
> >> Eli Zaretskii <eliz <at> gnu.org> writes:
> >> 
> >> >> Cc: Jonas Bernoulli <jonas <at> bernoul.li>
> >> >> Date: Thu, 27 Feb 2025 18:11:36 -0500
> >> >> From:  Spencer Baugh via "Bug reports for GNU Emacs,
> >> >>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> >> >> 
> >> >> 
> >> >> 1. emacs -Q
> >> >> 2. Position point over a button.el button, e.g.
> >> >>    (progn (view-emacs-news) (forward-button 1))
> >> >> 3. mouse-2 anywhere on the mode line.
> >> >> 4. Note that instead of the usual mouse-delete-other-windows binding,
> >> >>    the button at point is activated.
> >> >> 
> >> >> This is because the local keymap for buttons is button-map, which binds
> >> >> "<mode-line> <mouse-2>".  This is confusing, and probably a bug, but not
> >> >> too bad of a bug.
> >> >> 
> >> >> Substantially worse is this:
> >> >> 
> >> >> 5. mouse-1 on a part of the mode-line with a mouse-1 binding; for
> >> >>    example, mouse-1 on the buffer coding system indicator "U" at the
> >> >>    start of the mode line.
> >> >> 
> >> >> 6. Instead of describing the buffer's coding system, the button at point
> >> >>    is activated.
> >> >> 
> >> >> This is because mouse-1-click-follows-link translates the mouse-1 into a
> >> >> mouse-2.  This makes all mouse-1 bindings on the mode line basically
> >> >> broken while point is on a button.
> >> >
> >> > The bugs with mouse-1 are solved on the master branch (see bug#75219).
> >> > So I can reproduce the last two items in Emacs 30, but not in Emacs
> >> > 31.  The problems with mouse-2 are still present on the master branch.
> >> 
> >> The attached patch should fix the remaining bug, without dropping
> >> support for button.el in the mode-line or header-line.
> >> 
> >> >From 1ebb6e8822b5fc635549be14a3d4f2dd6f2d77a4 Mon Sep 17 00:00:00 2001
> >> From: Spencer Baugh <sbaugh <at> janestreet.com>
> >> Date: Thu, 28 Aug 2025 14:13:24 -0400
> >> Subject: [PATCH] Always ignore keymaps at point when clicking mode and header
> >>  line
> >> 
> >> In c41ea047a43, we started ignoring the keymap at point when a
> >> position is a click on the mode line or header line.  However,
> >> we only did this when POSN_STRING was non-nil, which isn't
> >> always the case for clicks on the mode line and header line.
> >> Move the check for mode line or header line outside the check
> >> for non-nil POSN_STRING so it takes effect in that case.
> >> 
> >> * src/keymap.c (Fcurrent_active_maps): Ignore keymaps at point
> >> for all clicks on mode and header line.  (bug#76620)
> >
> > I'm not sure I understand the logic of this change, so please
> > elaborate, by showing the form(s) of POSITION for which the current
> > code doesn't work, and please explain how this patch fixes that.
> 
> When you click on a part of the mode line which is after the end of
> mode-line-format, (at least on GNU/Linux) you get an event like this:
> 
> (down-mouse-1 (#<window 3 on *Bugs*> mode-line (2379 . 2071) 21536370
>  nil nil (157 . 88) nil (8 . 19) (15 . 32)))
> 
> posn-string is nil for this but it's still in the mode-line.  My change
> checks for whether a position is in the mode-line before checking if
> posn-string is nil, so it catches such events.

Ah, okay.  But what does this have to do with mouse-2 vs mouse-1?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: 76620 <at> debbugs.gnu.org, jonas <at> bernoul.li, monnier <at> iro.umontreal.ca
Subject: Re: bug#76620: 30.1.50; mouse-1 mode-line bindings are unusable
 when point is on a button
Date: Sat, 30 Aug 2025 17:05:49 +0300

> From: Spencer Baugh <sbaugh <at> janestreet.com>
> Cc: 76620 <at> debbugs.gnu.org,  jonas <at> bernoul.li,  monnier <at> iro.umontreal.ca
> Date: Sat, 30 Aug 2025 09:37:46 -0400
> 
> When you click on a part of the mode line which is after the end of
> mode-line-format, (at least on GNU/Linux) you get an event like this:
> 
> (down-mouse-1 (#<window 3 on *Bugs*> mode-line (2379 . 2071) 21536370
>  nil nil (157 . 88) nil (8 . 19) (15 . 32)))
> 
> posn-string is nil for this but it's still in the mode-line.  My change
> checks for whether a position is in the mode-line before checking if
> posn-string is nil, so it catches such events.

Btw, please make sure to test on TTY frames as well, AFAICT the format
of the event there is somewhat different, since there's no "end of
mode-line-format" on TTYs.

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

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 76620 <at> debbugs.gnu.org, jonas <at> bernoul.li, monnier <at> iro.umontreal.ca
Subject: Re: bug#76620: 30.1.50; mouse-1 mode-line bindings are unusable
 when point is on a button
Date: Sat, 30 Aug 2025 11:34:24 -0400

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Spencer Baugh <sbaugh <at> janestreet.com>
>> Cc: 76620 <at> debbugs.gnu.org,  jonas <at> bernoul.li,  monnier <at> iro.umontreal.ca
>> Date: Sat, 30 Aug 2025 09:37:46 -0400
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> >> From: Spencer Baugh <sbaugh <at> janestreet.com>
>> >> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>,  76620 <at> debbugs.gnu.org,
>> >>    jonas <at> bernoul.li
>> >> Date: Thu, 28 Aug 2025 14:22:32 -0400
>> >> 
>> >> Eli Zaretskii <eliz <at> gnu.org> writes:
>> >> 
>> >> >> Cc: Jonas Bernoulli <jonas <at> bernoul.li>
>> >> >> Date: Thu, 27 Feb 2025 18:11:36 -0500
>> >> >> From:  Spencer Baugh via "Bug reports for GNU Emacs,
>> >> >>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>> >> >> 
>> >> >> 
>> >> >> 1. emacs -Q
>> >> >> 2. Position point over a button.el button, e.g.
>> >> >>    (progn (view-emacs-news) (forward-button 1))
>> >> >> 3. mouse-2 anywhere on the mode line.
>> >> >> 4. Note that instead of the usual mouse-delete-other-windows binding,
>> >> >>    the button at point is activated.
>> >> >> 
>> >> >> This is because the local keymap for buttons is button-map, which binds
>> >> >> "<mode-line> <mouse-2>".  This is confusing, and probably a bug, but not
>> >> >> too bad of a bug.
>> >> >> 
>> >> >> Substantially worse is this:
>> >> >> 
>> >> >> 5. mouse-1 on a part of the mode-line with a mouse-1 binding; for
>> >> >>    example, mouse-1 on the buffer coding system indicator "U" at the
>> >> >>    start of the mode line.
>> >> >> 
>> >> >> 6. Instead of describing the buffer's coding system, the button at point
>> >> >>    is activated.
>> >> >> 
>> >> >> This is because mouse-1-click-follows-link translates the mouse-1 into a
>> >> >> mouse-2.  This makes all mouse-1 bindings on the mode line basically
>> >> >> broken while point is on a button.
>> >> >
>> >> > The bugs with mouse-1 are solved on the master branch (see bug#75219).
>> >> > So I can reproduce the last two items in Emacs 30, but not in Emacs
>> >> > 31.  The problems with mouse-2 are still present on the master branch.
>> >> 
>> >> The attached patch should fix the remaining bug, without dropping
>> >> support for button.el in the mode-line or header-line.
>> >> 
>> >> >From 1ebb6e8822b5fc635549be14a3d4f2dd6f2d77a4 Mon Sep 17 00:00:00 2001
>> >> From: Spencer Baugh <sbaugh <at> janestreet.com>
>> >> Date: Thu, 28 Aug 2025 14:13:24 -0400
>> >> Subject: [PATCH] Always ignore keymaps at point when clicking mode and header
>> >>  line
>> >> 
>> >> In c41ea047a43, we started ignoring the keymap at point when a
>> >> position is a click on the mode line or header line.  However,
>> >> we only did this when POSN_STRING was non-nil, which isn't
>> >> always the case for clicks on the mode line and header line.
>> >> Move the check for mode line or header line outside the check
>> >> for non-nil POSN_STRING so it takes effect in that case.
>> >> 
>> >> * src/keymap.c (Fcurrent_active_maps): Ignore keymaps at point
>> >> for all clicks on mode and header line.  (bug#76620)
>> >
>> > I'm not sure I understand the logic of this change, so please
>> > elaborate, by showing the form(s) of POSITION for which the current
>> > code doesn't work, and please explain how this patch fixes that.
>> 
>> When you click on a part of the mode line which is after the end of
>> mode-line-format, (at least on GNU/Linux) you get an event like this:
>> 
>> (down-mouse-1 (#<window 3 on *Bugs*> mode-line (2379 . 2071) 21536370
>>  nil nil (157 . 88) nil (8 . 19) (15 . 32)))
>> 
>> posn-string is nil for this but it's still in the mode-line.  My change
>> checks for whether a position is in the mode-line before checking if
>> posn-string is nil, so it catches such events.
>
> Ah, okay.  But what does this have to do with mouse-2 vs mouse-1?

Nothing at all - that was a red herring.  Fcurrent_active_maps returned
the wrong value (a value which included the keymaps at point) for both
mouse-2 and mouse-1, when the click was on the part of the mode line
after mode-line-format.

I think (though haven't checked) that the bug was only observable with
mouse-2 because of the quirks of mouse-1-click-follows-link.

BTW, I checked and the bug also seems to be fixed on TTY Emacs.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: monnier <at> iro.umontreal.ca, Spencer Baugh <sbaugh <at> janestreet.com>
Cc: 76620 <at> debbugs.gnu.org, jonas <at> bernoul.li
Subject: Re: bug#76620: 30.1.50; mouse-1 mode-line bindings are unusable
 when point is on a button
Date: Sat, 06 Sep 2025 11:40:00 +0300

Stefan, any comments to the patch?

> From: Spencer Baugh <sbaugh <at> janestreet.com>
> Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>,  76620 <at> debbugs.gnu.org,
>    jonas <at> bernoul.li
> Date: Thu, 28 Aug 2025 14:22:32 -0400
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> Cc: Jonas Bernoulli <jonas <at> bernoul.li>
> >> Date: Thu, 27 Feb 2025 18:11:36 -0500
> >> From:  Spencer Baugh via "Bug reports for GNU Emacs,
> >>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> >> 
> >> 
> >> 1. emacs -Q
> >> 2. Position point over a button.el button, e.g.
> >>    (progn (view-emacs-news) (forward-button 1))
> >> 3. mouse-2 anywhere on the mode line.
> >> 4. Note that instead of the usual mouse-delete-other-windows binding,
> >>    the button at point is activated.
> >> 
> >> This is because the local keymap for buttons is button-map, which binds
> >> "<mode-line> <mouse-2>".  This is confusing, and probably a bug, but not
> >> too bad of a bug.
> >> 
> >> Substantially worse is this:
> >> 
> >> 5. mouse-1 on a part of the mode-line with a mouse-1 binding; for
> >>    example, mouse-1 on the buffer coding system indicator "U" at the
> >>    start of the mode line.
> >> 
> >> 6. Instead of describing the buffer's coding system, the button at point
> >>    is activated.
> >> 
> >> This is because mouse-1-click-follows-link translates the mouse-1 into a
> >> mouse-2.  This makes all mouse-1 bindings on the mode line basically
> >> broken while point is on a button.
> >
> > The bugs with mouse-1 are solved on the master branch (see bug#75219).
> > So I can reproduce the last two items in Emacs 30, but not in Emacs
> > 31.  The problems with mouse-2 are still present on the master branch.
> 
> The attached patch should fix the remaining bug, without dropping
> support for button.el in the mode-line or header-line.
> 
> >From 1ebb6e8822b5fc635549be14a3d4f2dd6f2d77a4 Mon Sep 17 00:00:00 2001
> From: Spencer Baugh <sbaugh <at> janestreet.com>
> Date: Thu, 28 Aug 2025 14:13:24 -0400
> Subject: [PATCH] Always ignore keymaps at point when clicking mode and header
>  line
> 
> In c41ea047a43, we started ignoring the keymap at point when a
> position is a click on the mode line or header line.  However,
> we only did this when POSN_STRING was non-nil, which isn't
> always the case for clicks on the mode line and header line.
> Move the check for mode line or header line outside the check
> for non-nil POSN_STRING so it takes effect in that case.
> 
> * src/keymap.c (Fcurrent_active_maps): Ignore keymaps at point
> for all clicks on mode and header line.  (bug#76620)
> ---
>  src/keymap.c | 24 ++++++++++++------------
>  1 file changed, 12 insertions(+), 12 deletions(-)
> 
> diff --git a/src/keymap.c b/src/keymap.c
> index 2c250578b00..263bf336a71 100644
> --- a/src/keymap.c
> +++ b/src/keymap.c
> @@ -1735,6 +1735,16 @@ DEFUN ("current-active-maps", Fcurrent_active_maps, Scurrent_active_maps,
>  		}
>  	    }
>  
> +	  Lisp_Object pos_area = POSN_POSN (position);
> +	  if (EQ (pos_area, Qmode_line) || EQ (pos_area, Qheader_line))
> +	    {
> +	      /* For clicks on mode line or header line, ignore the maps
> +		 we found at POSITION, because properties at point are
> +		 not relevant in that case.  */
> +	      local_map = Qnil;
> +	      keymap = Qnil;
> +	    }
> +
>  	  /* If on a mode line string with a local keymap,
>  	     or for a click on a string, i.e. overlay string or a
>  	     string displayed via the `display' property,
> @@ -1751,20 +1761,10 @@ DEFUN ("current-active-maps", Fcurrent_active_maps, Scurrent_active_maps,
>  		{
>  		  Lisp_Object map = Fget_text_property (pos, Qlocal_map,
>  							string);
> -		  Lisp_Object pos_area = POSN_POSN (position);
> -		  /* For clicks on mode line or header line, override
> -		     the maps we found at POSITION unconditionally, even
> -		     if the corresponding properties of the mode- or
> -		     header-line string are nil, because propertries at
> -		     point are not relevant in that case.  */
> -		  if (!NILP (map)
> -		      || EQ (pos_area, Qmode_line)
> -		      || EQ (pos_area, Qheader_line))
> +		  if (!NILP (map))
>  		    local_map = map;
>  		  map = Fget_text_property (pos, Qkeymap, string);
> -		  if (!NILP (map)
> -		      || EQ (pos_area, Qmode_line)
> -		      || EQ (pos_area, Qheader_line))
> +		  if (!NILP (map))
>  		    keymap = map;
>  		}
>  	    }
> -- 
> 2.43.7
> 

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, jonas <at> bernoul.li, 76620 <at> debbugs.gnu.org
Subject: Re: bug#76620: 30.1.50; mouse-1 mode-line bindings are unusable
 when point is on a button
Date: Sun, 07 Sep 2025 11:21:06 -0400

>> I'm not sure I understand the logic of this change, so please
>> elaborate, by showing the form(s) of POSITION for which the current
>> code doesn't work, and please explain how this patch fixes that.
> When you click on a part of the mode line which is after the end of
> mode-line-format, (at least on GNU/Linux) you get an event like this:
>
> (down-mouse-1 (#<window 3 on *Bugs*> mode-line (2379 . 2071) 21536370
>  nil nil (157 . 88) nil (8 . 19) (15 . 32)))
>
> posn-string is nil for this but it's still in the mode-line.  My change
> checks for whether a position is in the mode-line before checking if
> posn-string is nil, so it catches such events.

I suspect this answer (in one way or another) should find its way either
into a comment or into the commit message.
[ I tend to have that impression for most questions that occur during
  a code review, tho, so maybe it's just me.  ]

I have a more demanding request: any chance we could concoct an ERT test
for that?  I realize that it might be difficult, but we keep skipping
such "UI" tests because they're difficult, so I think we should try to
slowly get closer to having an actual test suite of the UI elements.
If you can identify one obstacle that makes it currently impossible,
maybe we can fix that obstacle, and thus make one step in that direction.


        Stefan

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

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, jonas <at> bernoul.li, 76620 <at> debbugs.gnu.org
Subject: Re: bug#76620: 30.1.50; mouse-1 mode-line bindings are unusable
 when point is on a button
Date: Mon, 08 Sep 2025 16:49:59 -0400

[Message part 1 (text/plain, inline)]

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>>> I'm not sure I understand the logic of this change, so please
>>> elaborate, by showing the form(s) of POSITION for which the current
>>> code doesn't work, and please explain how this patch fixes that.
>> When you click on a part of the mode line which is after the end of
>> mode-line-format, (at least on GNU/Linux) you get an event like this:
>>
>> (down-mouse-1 (#<window 3 on *Bugs*> mode-line (2379 . 2071) 21536370
>>  nil nil (157 . 88) nil (8 . 19) (15 . 32)))
>>
>> posn-string is nil for this but it's still in the mode-line.  My change
>> checks for whether a position is in the mode-line before checking if
>> posn-string is nil, so it catches such events.
>
> I suspect this answer (in one way or another) should find its way either
> into a comment or into the commit message.
> [ I tend to have that impression for most questions that occur during
>   a code review, tho, so maybe it's just me.  ]

I agree, I added it to the commit message.

> I have a more demanding request: any chance we could concoct an ERT test
> for that?  I realize that it might be difficult, but we keep skipping
> such "UI" tests because they're difficult, so I think we should try to
> slowly get closer to having an actual test suite of the UI elements.
> If you can identify one obstacle that makes it currently impossible,
> maybe we can fix that obstacle, and thus make one step in that direction.

A very reasonable request, I think.  How about the test in the attached
patch?  It's not really an end-to-end test, but I think it's still
useful.

In fact, while writing this test, I noticed another bug in this code,
which I've now also fixed.  Good call :)

The test would be improved if we had a nice way to generate click events
from Lisp.  Then I could write some code which does "click on the mode
line" and test that that has the right behavior.  But I have no idea how
to do that, is there even a way?

[0001-Ignore-keymaps-at-point-for-positions-outside-the-bu.patch (text/x-patch, inline)]

From 40881a88b06f3f6bbda2f48b7be908ef49e02d74 Mon Sep 17 00:00:00 2001
From: Spencer Baugh <sbaugh <at> janestreet.com>
Date: Thu, 28 Aug 2025 14:13:24 -0400
Subject: [PATCH] Ignore keymaps at point for positions outside the buffer

Correct a few edge cases where we used the keymaps at point when
looking up keymaps for an event position which is outside the
current buffer.  Namely:

- Clicking on a part of the mode line which is after the end of
  mode-line-format produces an event with non-nil posn-area but
  nil posn-string.

- Even if posn-string doesn't have a local keymap, we should
  still ignore the keymaps at point if posn-string is non-nil.

* src/keymap.c (Fcurrent_active_maps): Ignore keymaps at point
for more positions outside the buffer.  (bug#76620)
---
 src/keymap.c             | 38 ++++++++++++++++----------------------
 test/src/keymap-tests.el | 27 +++++++++++++++++++++++++++
 2 files changed, 43 insertions(+), 22 deletions(-)

diff --git a/src/keymap.c b/src/keymap.c
index 2c250578b00..295b209f06b 100644
--- a/src/keymap.c
+++ b/src/keymap.c
@@ -1735,11 +1735,20 @@ DEFUN ("current-active-maps", Fcurrent_active_maps, Scurrent_active_maps,
 		}
 	    }
 
-	  /* If on a mode line string with a local keymap,
-	     or for a click on a string, i.e. overlay string or a
-	     string displayed via the `display' property,
-	     consider `local-map' and `keymap' properties of
-	     that string.  */
+	  Lisp_Object pos_area = POSN_POSN (position);
+	  if (EQ (pos_area, Qmode_line) || EQ (pos_area, Qheader_line))
+	    {
+	      /* For clicks on mode line or header line, ignore the maps
+		 we found at POSITION, because properties at point are
+		 not relevant in that case.  */
+	      local_map = Qnil;
+	      keymap = Qnil;
+	    }
+
+	  /* If on a mode line string with a local keymap, or for a
+	     click on a string, i.e. overlay string or a string
+	     displayed via the `display' property, consider only the
+	     `local-map' and `keymap' properties of that string.  */
 
 	  if (CONSP (string) && STRINGP (XCAR (string)))
 	    {
@@ -1749,23 +1758,8 @@ DEFUN ("current-active-maps", Fcurrent_active_maps, Scurrent_active_maps,
 		  && XFIXNUM (pos) >= 0
 		  && XFIXNUM (pos) < SCHARS (string))
 		{
-		  Lisp_Object map = Fget_text_property (pos, Qlocal_map,
-							string);
-		  Lisp_Object pos_area = POSN_POSN (position);
-		  /* For clicks on mode line or header line, override
-		     the maps we found at POSITION unconditionally, even
-		     if the corresponding properties of the mode- or
-		     header-line string are nil, because propertries at
-		     point are not relevant in that case.  */
-		  if (!NILP (map)
-		      || EQ (pos_area, Qmode_line)
-		      || EQ (pos_area, Qheader_line))
-		    local_map = map;
-		  map = Fget_text_property (pos, Qkeymap, string);
-		  if (!NILP (map)
-		      || EQ (pos_area, Qmode_line)
-		      || EQ (pos_area, Qheader_line))
-		    keymap = map;
+		  local_map = Fget_text_property (pos, Qlocal_map, string);
+		  keymap = Fget_text_property (pos, Qkeymap, string);
 		}
 	    }
 
diff --git a/test/src/keymap-tests.el b/test/src/keymap-tests.el
index c605c3eb09d..950c741a6dd 100644
--- a/test/src/keymap-tests.el
+++ b/test/src/keymap-tests.el
@@ -509,6 +509,33 @@ keymap-unset-test-remove-and-inheritance
     ;; From the parent this time/
     (should (equal (keymap-lookup map "u") #'undo))))
 
+(defun keymap-test--maps-for-posn (area string)
+  (current-active-maps
+   nil
+   ;; FIXME: This test would be better if this was a real position
+   ;; created by a real click.
+   `(,(selected-window) ,area (1 . 1) 0 (,string . 0) nil (1 . 1) nil (1 . 1) (1 . 1))))
+
+(ert-deftest keymap-test-keymaps-for-non-buffer-positions ()
+  "`current-active-maps' with non-buffer positions.  (bug#76620)"
+  (with-temp-buffer
+    (pop-to-buffer (current-buffer))
+    (let ((keymap (make-sparse-keymap "keymap-at-point")))
+      (insert (propertize "string" 'keymap keymap))
+      (goto-char (point-min))
+      (should (memq keymap (current-active-maps)))
+      (should-not (memq keymap (keymap-test--maps-for-posn 'mode-line nil)))
+      (should-not (memq keymap (keymap-test--maps-for-posn 'mode-line "s")))
+      (should-not (memq keymap (keymap-test--maps-for-posn nil "s")))
+      (should (memq keymap (keymap-test--maps-for-posn nil nil)))
+      (let* ((mode-line-keymap (make-sparse-keymap "keymap-in-mode-line"))
+             (s (propertize "string" 'keymap mode-line-keymap)))
+        ;; Respect `keymap' in the string clicked on.
+        (should-not (memq keymap (keymap-test--maps-for-posn nil s)))
+        (should-not (memq keymap (keymap-test--maps-for-posn 'mode-line s)))
+        (should (memq mode-line-keymap (keymap-test--maps-for-posn nil s)))
+        (should (memq mode-line-keymap (keymap-test--maps-for-posn 'mode-line s)))))))
+
 (provide 'keymap-tests)
 
 ;;; keymap-tests.el ends here
-- 
2.43.7

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, jonas <at> bernoul.li, 76620 <at> debbugs.gnu.org
Subject: Re: bug#76620: 30.1.50; mouse-1 mode-line bindings are unusable
 when point is on a button
Date: Mon, 08 Sep 2025 18:17:43 -0400

>> I have a more demanding request: any chance we could concoct an ERT test
>> for that?  I realize that it might be difficult, but we keep skipping
>> such "UI" tests because they're difficult, so I think we should try to
>> slowly get closer to having an actual test suite of the UI elements.
>> If you can identify one obstacle that makes it currently impossible,
>> maybe we can fix that obstacle, and thus make one step in that direction.
> A very reasonable request, I think.  How about the test in the attached
> patch?  It's not really an end-to-end test, but I think it's still
> useful.

Thanks, looks good.

> Then I could write some code which does "click on the mode
> line" and test that that has the right behavior.

Yeah, tho it's not completely clear how to write "click on the mode
line" in code (including specifying where on the mode line).

> But I have no idea how to do that, is there even a way?

In the past, some mentioned running a TTY session of Emacs inside
a nested inside a `M-x term` buffer.  But maybe some clever use of
`posn-at-x-y` could help build up the posn objects in your test in
a more "intentional way".

In the mean time, I'm happy with your test.

Eli, should I push it?


        Stefan

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: sbaugh <at> janestreet.com, 76620 <at> debbugs.gnu.org, jonas <at> bernoul.li
Subject: Re: bug#76620: 30.1.50; mouse-1 mode-line bindings are unusable
 when point is on a button
Date: Tue, 09 Sep 2025 14:42:46 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  jonas <at> bernoul.li,  76620 <at> debbugs.gnu.org
> Date: Mon, 08 Sep 2025 18:17:43 -0400
> 
> >> I have a more demanding request: any chance we could concoct an ERT test
> >> for that?  I realize that it might be difficult, but we keep skipping
> >> such "UI" tests because they're difficult, so I think we should try to
> >> slowly get closer to having an actual test suite of the UI elements.
> >> If you can identify one obstacle that makes it currently impossible,
> >> maybe we can fix that obstacle, and thus make one step in that direction.
> > A very reasonable request, I think.  How about the test in the attached
> > patch?  It's not really an end-to-end test, but I think it's still
> > useful.
> 
> Thanks, looks good.
> 
> > Then I could write some code which does "click on the mode
> > line" and test that that has the right behavior.
> 
> Yeah, tho it's not completely clear how to write "click on the mode
> line" in code (including specifying where on the mode line).
> 
> > But I have no idea how to do that, is there even a way?
> 
> In the past, some mentioned running a TTY session of Emacs inside
> a nested inside a `M-x term` buffer.  But maybe some clever use of
> `posn-at-x-y` could help build up the posn objects in your test in
> a more "intentional way".
> 
> In the mean time, I'm happy with your test.
> 
> Eli, should I push it?

Yes, please.

Message #58 received at 76620-done <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, jonas <at> bernoul.li, 76620-done <at> debbugs.gnu.org
Subject: Re: bug#76620: 30.1.50; mouse-1 mode-line bindings are unusable
 when point is on a button
Date: Tue, 09 Sep 2025 18:08:47 -0400

> A very reasonable request, I think.  How about the test in the attached
> patch?  It's not really an end-to-end test, but I think it's still
> useful.

Pushed to `master`, thanks, closing,


        Stefan

Previous Next

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