GNU bug report logs - #79505
31.0.50; down-mouse-1 on text with display property stopped working since 0e9cee2bf5d97a23c47d99ffc47396dcd3bd50ee

Previous Next

To reply to this bug, email your comments to 79505 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: Daniel Mendler <mail <at> daniel-mendler.de>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; down-mouse-1 on text with display property stopped working
 since 0e9cee2bf5d97a23c47d99ffc47396dcd3bd50ee
Date: Wed, 24 Sep 2025 19:57:33 +0200

Since 0e9cee2bf5d97a23c47d99ffc47396dcd3bd50ee down-mouse-1 stopped
working on text with display properties. The problem occurs with the
following example configuration starting from emacs -Q:

(package-initialize)
(require 'org)
(require 'org-mouse)
(global-org-modern-mode) ;; Requires the org-modern package from GNU ELPA

`org-modern-mode' replaces the Org headline stars with Unicode triangles
via a display string. Clicking on the triangle should fold or unfold the
text below the headline.

The keymap configuration is as follows:

- `org-mode-map' has a `down-mouse-1' binding to `org-mouse-down-mouse'.
- `global-map' has a `down-mouse-1' binding to `mouse-drag-region'.
- The text has a keymap property, but no binding for `mouse-1' or `down-mouse-1'.
- The display replacement text has no keymap property.

Reverting 0e9cee2bf5d97a23c47d99ffc47396dcd3bd50ee fixes the problem.

In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.49, cairo version 1.18.4) of 2025-09-24
Windowing system distributor 'The X.Org Foundation', version 11.0.12101016
System Description: Debian GNU/Linux 13 (trixie)

Configured using:
 'configure --prefix=$HOME/.local/share/emacs
 --without-compress-install --with-tree-sitter --with-native-compilation
 --with-dbus --without-selinux --without-threads --disable-gc-mark-trace
 --without-gsettings --without-gpm --with-cairo --with-cairo-xcb
 --with-xinput2 --with-x-toolkit=gtk3 --without-toolkit-scroll-bars
 'CFLAGS=-O3 -mtune=native -march=native''

Configured features:
CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS HARFBUZZ JPEG LIBOTF LIBSYSTEMD
LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP
SOUND SQLITE3 TIFF TREE_SITTER WEBP X11 XDBE XIM XINERAMA XINPUT2 XPM
XRANDR GTK3 ZLIB

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

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: 79505 <at> debbugs.gnu.org
Subject: Re: bug#79505: 31.0.50; down-mouse-1 on text with display property
 stopped working since 0e9cee2bf5d97a23c47d99ffc47396dcd3bd50ee
Date: Wed, 24 Sep 2025 14:17:52 -0400

Daniel Mendler <mail <at> daniel-mendler.de> writes:
> Since 0e9cee2bf5d97a23c47d99ffc47396dcd3bd50ee down-mouse-1 stopped
> working on text with display properties. The problem occurs with the
> following example configuration starting from emacs -Q:
>
> (package-initialize)
> (require 'org)
> (require 'org-mouse)
> (global-org-modern-mode) ;; Requires the org-modern package from GNU ELPA
>
> `org-modern-mode' replaces the Org headline stars with Unicode triangles
> via a display string. Clicking on the triangle should fold or unfold the
> text below the headline.
>
> The keymap configuration is as follows:
>
> - `org-mode-map' has a `down-mouse-1' binding to `org-mouse-down-mouse'.
> - `global-map' has a `down-mouse-1' binding to `mouse-drag-region'.
> - The text has a keymap property, but no binding for `mouse-1' or `down-mouse-1'.
> - The display replacement text has no keymap property.
>
> Reverting 0e9cee2bf5d97a23c47d99ffc47396dcd3bd50ee fixes the problem.

Thanks for the report.  Can you run M-: (read-event) and click on the
relevant text, and report what that outputs?

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: 79505 <at> debbugs.gnu.org
Subject: Re: bug#79505: 31.0.50; down-mouse-1 on text with display property
 stopped working since 0e9cee2bf5d97a23c47d99ffc47396dcd3bd50ee
Date: Wed, 24 Sep 2025 20:19:47 +0200

Spencer Baugh <sbaugh <at> janestreet.com> writes:

> Daniel Mendler <mail <at> daniel-mendler.de> writes:
>> Since 0e9cee2bf5d97a23c47d99ffc47396dcd3bd50ee down-mouse-1 stopped
>> working on text with display properties. The problem occurs with the
>> following example configuration starting from emacs -Q:
>>
>> (package-initialize)
>> (require 'org)
>> (require 'org-mouse)
>> (global-org-modern-mode) ;; Requires the org-modern package from GNU ELPA
>>
>> `org-modern-mode' replaces the Org headline stars with Unicode triangles
>> via a display string. Clicking on the triangle should fold or unfold the
>> text below the headline.
>>
>> The keymap configuration is as follows:
>>
>> - `org-mode-map' has a `down-mouse-1' binding to `org-mouse-down-mouse'.
>> - `global-map' has a `down-mouse-1' binding to `mouse-drag-region'.
>> - The text has a keymap property, but no binding for `mouse-1' or `down-mouse-1'.
>> - The display replacement text has no keymap property.
>>
>> Reverting 0e9cee2bf5d97a23c47d99ffc47396dcd3bd50ee fixes the problem.
>
> Thanks for the report.  Can you run M-: (read-event) and click on the
> relevant text, and report what that outputs?

With 0e9cee2bf5d97a23c47d99ffc47396dcd3bd50ee reverted I get the
following on a click:

(down-mouse-1 (#<window 7 on example.org> 176 (8 . 251) 83587687 (#("▶"
0 1 ...) . 0) 176 (0 . 9) nil (8 . 22) (20 . 26)))

Daniel

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

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: 79505 <at> debbugs.gnu.org
Subject: Re: bug#79505: 31.0.50; down-mouse-1 on text with display property
 stopped working since 0e9cee2bf5d97a23c47d99ffc47396dcd3bd50ee
Date: Fri, 26 Sep 2025 18:16:01 -0400

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

Daniel Mendler <mail <at> daniel-mendler.de> writes:

> Spencer Baugh <sbaugh <at> janestreet.com> writes:
>
>> Daniel Mendler <mail <at> daniel-mendler.de> writes:
>>> Since 0e9cee2bf5d97a23c47d99ffc47396dcd3bd50ee down-mouse-1 stopped
>>> working on text with display properties. The problem occurs with the
>>> following example configuration starting from emacs -Q:
>>>
>>> (package-initialize)
>>> (require 'org)
>>> (require 'org-mouse)
>>> (global-org-modern-mode) ;; Requires the org-modern package from GNU ELPA
>>>
>>> `org-modern-mode' replaces the Org headline stars with Unicode triangles
>>> via a display string. Clicking on the triangle should fold or unfold the
>>> text below the headline.
>>>
>>> The keymap configuration is as follows:
>>>
>>> - `org-mode-map' has a `down-mouse-1' binding to `org-mouse-down-mouse'.
>>> - `global-map' has a `down-mouse-1' binding to `mouse-drag-region'.
>>> - The text has a keymap property, but no binding for `mouse-1' or `down-mouse-1'.
>>> - The display replacement text has no keymap property.
>>>
>>> Reverting 0e9cee2bf5d97a23c47d99ffc47396dcd3bd50ee fixes the problem.
>>
>> Thanks for the report.  Can you run M-: (read-event) and click on the
>> relevant text, and report what that outputs?
>
> With 0e9cee2bf5d97a23c47d99ffc47396dcd3bd50ee reverted I get the
> following on a click:
>
> (down-mouse-1 (#<window 7 on example.org> 176 (8 . 251) 83587687 (#("▶"
> 0 1 ...) . 0) 176 (0 . 9) nil (8 . 22) (20 . 26)))
>
> Daniel

Thanks.  Could you try this patch?

[0001-Respect-keymaps-in-buffer-text-for-clicks-on-display.patch (text/x-patch, inline)]

From c3afcfb0a8b7d11189fadb259b10b4c41286696b Mon Sep 17 00:00:00 2001
From: Spencer Baugh <sbaugh <at> janestreet.com>
Date: Fri, 26 Sep 2025 18:13:30 -0400
Subject: [PATCH] Respect keymaps in buffer text for clicks on displayed
 strings

When clicking on a string displayed by a display property, also
look at the text properties of the underlying buffer text for
keymaps, not just the displayed string.  The displayed string
takes precedence over the buffer text, but it doesn't replace
it.

Also, we should use the buffer's local map even for clicks on
the mode line.  (Otherwise, what's the point of the <mode-line>
event?)

* src/keymap.c (Fcurrent_active_maps): Consider displayed
string, then buffer text, then fall back to local
map. (bug#79505)
* test/src/keymap-tests.el
(keymap-test-keymaps-for-non-buffer-positions): Add more tests.
---
 src/keymap.c             | 47 ++++++++++++++++++++--------------------
 test/src/keymap-tests.el | 21 +++++++++++++-----
 2 files changed, 39 insertions(+), 29 deletions(-)

diff --git a/src/keymap.c b/src/keymap.c
index 295b209f06b..a01dee1476b 100644
--- a/src/keymap.c
+++ b/src/keymap.c
@@ -1721,33 +1721,12 @@ DEFUN ("current-active-maps", Fcurrent_active_maps, Scurrent_active_maps,
 	  /* For a mouse click, get the local text-property keymap
 	     of the place clicked on, rather than point.  */
 
-	  if (POSN_INBUFFER_P (position))
-	    {
-	      Lisp_Object pos = POSN_BUFFER_POSN (position);
-	      if (FIXNUMP (pos)
-		  && XFIXNUM (pos) >= BEG && XFIXNUM (pos) <= Z)
-		{
-		  local_map = get_local_map (XFIXNUM (pos),
-					     current_buffer, Qlocal_map);
-
-		  keymap = get_local_map (XFIXNUM (pos),
-					  current_buffer, Qkeymap);
-		}
-	    }
-
-	  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;
-	    }
+	  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
+	     displayed via the `display' property, first consider the
 	     `local-map' and `keymap' properties of that string.  */
 
 	  if (CONSP (string) && STRINGP (XCAR (string)))
@@ -1763,6 +1742,26 @@ DEFUN ("current-active-maps", Fcurrent_active_maps, Scurrent_active_maps,
 		}
 	    }
 
+	  Lisp_Object buffer_posn = POSN_BUFFER_POSN (position);
+	  /* Then, if the click was in the buffer, get the local
+	     text-property keymap of the place clicked on.  */
+
+	  if (FIXNUMP (buffer_posn)
+	      && XFIXNUM (buffer_posn) >= BEG && XFIXNUM (buffer_posn) <= Z)
+	    {
+	      /* The properties in POSN_STRING take precedence, if set. */
+	      if (NILP (local_map))
+		local_map = get_local_map (XFIXNUM (buffer_posn),
+					   current_buffer, Qlocal_map);
+
+	      if (NILP (keymap))
+		keymap = get_local_map (XFIXNUM (buffer_posn),
+					current_buffer, Qkeymap);
+	    }
+
+	  /* Finally, fall back on the buffer's local map. */
+	  if (NILP (local_map))
+	    local_map = BVAR (current_buffer, keymap);
 	}
 
       if (!NILP (local_map))
diff --git a/test/src/keymap-tests.el b/test/src/keymap-tests.el
index 950c741a6dd..0d203f6fcb0 100644
--- a/test/src/keymap-tests.el
+++ b/test/src/keymap-tests.el
@@ -509,25 +509,36 @@ keymap-unset-test-remove-and-inheritance
     ;; From the parent this time/
     (should (equal (keymap-lookup map "u") #'undo))))
 
+(defun keymap-test--get-maps (posn)
+  (let ((maps (current-active-maps nil posn)))
+    ;; The local map should always be present.
+    (should (memq (current-local-map) maps))
+    maps))
+
 (defun keymap-test--maps-for-posn (area string)
-  (current-active-maps
-   nil
+  (keymap-test--get-maps
    ;; 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))))
+   (let (;; If AREA is passed, the click isn't in the buffer; otherwise
+         ;; it's at position 1.
+         (pos (if area nil 1)))
+     `(,(selected-window) ,area (1 . 1) 0 (,string . 0)
+       ,pos (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")))
+      (use-local-map (make-sparse-keymap "buffer-local-map"))
       (insert (propertize "string" 'keymap keymap))
       (goto-char (point-min))
-      (should (memq keymap (current-active-maps)))
+      (should (memq keymap (keymap-test--get-maps nil)))
       (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 "s")))
       (should (memq keymap (keymap-test--maps-for-posn nil nil)))
+      (should (memq keymap (keymap-test--get-maps "a")))
       (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.
-- 
2.43.7

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: 79505 <at> debbugs.gnu.org
Subject: Re: bug#79505: 31.0.50; down-mouse-1 on text with display property  stopped working since 0e9cee2bf5d97a23c47d99ffc47396dcd3bd50ee
Date: Sat, 27 Sep 2025 07:23:10 +0200

Thanks. This looks like a larger change. Why not first revert 0e9cee2bf5d97a23c47d99ffc47396dcd3bd50ee? I wonder what the risks are of introducing new regressions. I can test in a few days.

Daniel

Am 27. September 2025 00:16:01 MESZ schrieb Spencer Baugh <sbaugh <at> janestreet.com>:
>Daniel Mendler <mail <at> daniel-mendler.de> writes:
>
>> Spencer Baugh <sbaugh <at> janestreet.com> writes:
>>
>>> Daniel Mendler <mail <at> daniel-mendler.de> writes:
>>>> Since 0e9cee2bf5d97a23c47d99ffc47396dcd3bd50ee down-mouse-1 stopped
>>>> working on text with display properties. The problem occurs with the
>>>> following example configuration starting from emacs -Q:
>>>>
>>>> (package-initialize)
>>>> (require 'org)
>>>> (require 'org-mouse)
>>>> (global-org-modern-mode) ;; Requires the org-modern package from GNU ELPA
>>>>
>>>> `org-modern-mode' replaces the Org headline stars with Unicode triangles
>>>> via a display string. Clicking on the triangle should fold or unfold the
>>>> text below the headline.
>>>>
>>>> The keymap configuration is as follows:
>>>>
>>>> - `org-mode-map' has a `down-mouse-1' binding to `org-mouse-down-mouse'.
>>>> - `global-map' has a `down-mouse-1' binding to `mouse-drag-region'.
>>>> - The text has a keymap property, but no binding for `mouse-1' or `down-mouse-1'.
>>>> - The display replacement text has no keymap property.
>>>>
>>>> Reverting 0e9cee2bf5d97a23c47d99ffc47396dcd3bd50ee fixes the problem.
>>>
>>> Thanks for the report.  Can you run M-: (read-event) and click on the
>>> relevant text, and report what that outputs?
>>
>> With 0e9cee2bf5d97a23c47d99ffc47396dcd3bd50ee reverted I get the
>> following on a click:
>>
>> (down-mouse-1 (#<window 7 on example.org> 176 (8 . 251) 83587687 (#("▶"
>> 0 1 ...) . 0) 176 (0 . 9) nil (8 . 22) (20 . 26)))
>>
>> Daniel
>
>Thanks.  Could you try this patch?
>

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

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Daniel Mendler <mail <at> daniel-mendler.de>
Cc: 79505 <at> debbugs.gnu.org
Subject: Re: bug#79505: 31.0.50; down-mouse-1 on text with display property
 stopped working since 0e9cee2bf5d97a23c47d99ffc47396dcd3bd50ee
Date: Tue, 30 Sep 2025 14:51:08 -0400

Daniel Mendler <mail <at> daniel-mendler.de> writes:
> Thanks. This looks like a larger change. Why not first revert
> 0e9cee2bf5d97a23c47d99ffc47396dcd3bd50ee?

Because that would reintroduce the original bug that that commit fixed.

> I wonder what the risks are of introducing new regressions.

I don't know either, but that's why I added more tests.  If there are
more regressions after this change, then I'll add even more tests.

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: 79505 <at> debbugs.gnu.org
Subject: Re: bug#79505: 31.0.50; down-mouse-1 on text with display property  stopped working since 0e9cee2bf5d97a23c47d99ffc47396dcd3bd50ee
Date: Wed, 01 Oct 2025 00:07:58 +0200

Am 30. September 2025 20:51:08 MESZ schrieb Spencer Baugh <sbaugh <at> janestreet.com>:
>Daniel Mendler <mail <at> daniel-mendler.de> writes:
>> Thanks. This looks like a larger change. Why not first revert
>> 0e9cee2bf5d97a23c47d99ffc47396dcd3bd50ee?
>
>Because that would reintroduce the original bug that that commit fixed.

Obviously. But your fix introduced a regression, so it changed too much or in the wrong way. What matters is if the old plus the new patch modified the logic in a way to only fix the old bug.

>> I wonder what the risks are of introducing new regressions.
>
>I don't know either, but that's why I added more tests.  If there are
>more regressions after this change, then I'll add even more tests.

This is not an approach I find trustworthy. Therefore my question above.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Mendler <mail <at> daniel-mendler.de>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: sbaugh <at> janestreet.com, 79505 <at> debbugs.gnu.org
Subject: Re: bug#79505: 31.0.50;
 down-mouse-1 on text with display property stopped working since
 0e9cee2bf5d97a23c47d99ffc47396dcd3bd50ee
Date: Sat, 04 Oct 2025 10:50:16 +0300

> Cc: 79505 <at> debbugs.gnu.org
> Date: Wed, 01 Oct 2025 00:07:58 +0200
> From:  Daniel Mendler via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> 
> 
> Am 30. September 2025 20:51:08 MESZ schrieb Spencer Baugh <sbaugh <at> janestreet.com>:
> >Daniel Mendler <mail <at> daniel-mendler.de> writes:
> >> Thanks. This looks like a larger change. Why not first revert
> >> 0e9cee2bf5d97a23c47d99ffc47396dcd3bd50ee?
> >
> >Because that would reintroduce the original bug that that commit fixed.
> 
> Obviously. But your fix introduced a regression, so it changed too much or in the wrong way. What matters is if the old plus the new patch modified the logic in a way to only fix the old bug.
> 
> >> I wonder what the risks are of introducing new regressions.
> >
> >I don't know either, but that's why I added more tests.  If there are
> >more regressions after this change, then I'll add even more tests.
> 
> This is not an approach I find trustworthy. Therefore my question above.

Perhaps Stefan has some comments or suggestions?

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: Daniel Mendler <mail <at> daniel-mendler.de>, 79505 <at> debbugs.gnu.org
Subject: Re: bug#79505: 31.0.50; down-mouse-1 on text with display property
 stopped working since 0e9cee2bf5d97a23c47d99ffc47396dcd3bd50ee
Date: Sun, 12 Oct 2025 13:08:16 -0400

> When clicking on a string displayed by a display property, also look
> at the text properties of the underlying buffer text for keymaps, not
> just the displayed string.  The displayed string takes precedence over
> the buffer text, but it doesn't replace it.
>
> Also, we should use the buffer's local map even for clicks on
> the mode line.  (Otherwise, what's the point of the <mode-line>
> event?)

Thanks.  The patch looks good, it even makes the code a bit easier
to read IMO.


        Stefan

Message #34 received at 79505-done <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, 79505-done <at> debbugs.gnu.org, mail <at> daniel-mendler.de
Subject: Re: bug#79505: 31.0.50;
 down-mouse-1 on text with display property stopped working since
 0e9cee2bf5d97a23c47d99ffc47396dcd3bd50ee
Date: Sat, 18 Oct 2025 12:51:50 +0300

> Cc: Daniel Mendler <mail <at> daniel-mendler.de>, 79505 <at> debbugs.gnu.org
> Date: Sun, 12 Oct 2025 13:08:16 -0400
> From:  Stefan Monnier via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> > When clicking on a string displayed by a display property, also look
> > at the text properties of the underlying buffer text for keymaps, not
> > just the displayed string.  The displayed string takes precedence over
> > the buffer text, but it doesn't replace it.
> >
> > Also, we should use the buffer's local map even for clicks on
> > the mode line.  (Otherwise, what's the point of the <mode-line>
> > event?)
> 
> Thanks.  The patch looks good, it even makes the code a bit easier
> to read IMO.

Thanks, now installed on master, and closing the bug.

Previous Next

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