GNU bug report logs - #79305
31.0.50; MODE-set-explicitly change caused regressions in bind-map

Previous Next

To reply to this bug, email your comments to 79305 AT debbugs.gnu.org.

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

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

From: Aaron Jensen <aaronjensen <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; MODE-set-explicitly change caused regressions in bind-map
Date: Sun, 24 Aug 2025 15:17:47 -0700

This may be as expected as it sounds like MODE-set-explicitly is meant
to be internal, but I wanted to report it in case regressions were not
expected.

The change:
https://github.com/emacs-mirror/emacs/commit/c05ea64d8268315093673f8be29d4ceb92198b81

The 3rd-party library's use of *-set-explicitly:
https://github.com/justbur/emacs-bind-map/blob/f23cfc13222a39e686d28a83ff83e9901d8908b2/bind-map.el#L180

After the change, bind-map no longer successfully overrides maps. I
don't know the specifics of why it doesn't work, but correcting the
formatting of the name to use the format string "%s--set-explicitly"
restores functionality.

I've opened an issue in bind-map so that it can be addressed there if
that's appropriate. Please feel free to close this if this is expected
and acceptable.

Thank you,

Aaron

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

From: "Aaron Jensen" <aaronjensen <at> gmail.com>
To: "Emacs Bugs" <bug-gnu-emacs <at> gnu.org>
Cc: spwhitton <at> spwhitton.name
Subject: bug#79305: 31.0.50; MODE-set-explicitly change caused regressions
 in bind-map
Date: Tue, 26 Aug 2025 15:53:27 +0000

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

Adding Sean, the author of the commit, as I forgot to CC them initially.

Aaron

[Message part 2 (text/html, inline)]

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Aaron Jensen <aaronjensen <at> gmail.com>, Stefan Monnier
 <monnier <at> iro.umontreal.ca>, Jonas Bernoulli <jonas <at> bernoul.li>
Cc: 79305 <at> debbugs.gnu.org
Subject: Re: bug#79305: 31.0.50; MODE-set-explicitly change caused
 regressions in bind-map
Date: Thu, 28 Aug 2025 08:59:31 +0100

Hello,

Thanks.  This was not intended to be a breaking change.

On Sun 24 Aug 2025 at 03:17pm -07, Aaron Jensen wrote:

> This may be as expected as it sounds like MODE-set-explicitly is meant
> to be internal, but I wanted to report it in case regressions were not
> expected.
>
> The change:
> https://github.com/emacs-mirror/emacs/commit/c05ea64d8268315093673f8be29d4ceb92198b81
>
> The 3rd-party library's use of *-set-explicitly:
> https://github.com/justbur/emacs-bind-map/blob/f23cfc13222a39e686d28a83ff83e9901d8908b2/bind-map.el#L180
>
> After the change, bind-map no longer successfully overrides maps. I
> don't know the specifics of why it doesn't work, but correcting the
> formatting of the name to use the format string "%s--set-explicitly"
> restores functionality.
>
> I've opened an issue in bind-map so that it can be addressed there if
> that's appropriate. Please feel free to close this if this is expected
> and acceptable.

bind-map shouldn't use an internal variable like that.

If there is no other way for bind-map to achieve what it needs, and we
think what it is trying to do is a reasonable interaction with
define-globalized-minor-mode, we should undo the renaming of the
variable.

Otherwise we should declare the variable obsolete instead of just
renaming it outright, so that any other third party package authors have
a chance to make updates.

Stefan, Jonas, what do you think?

-- 
Sean Whitton

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: Jonas Bernoulli <jonas <at> bernoul.li>, 79305 <at> debbugs.gnu.org,
 Aaron Jensen <aaronjensen <at> gmail.com>
Subject: Re: bug#79305: 31.0.50; MODE-set-explicitly change caused
 regressions in bind-map
Date: Fri, 29 Aug 2025 10:43:44 -0400

> bind-map shouldn't use an internal variable like that.

+1, tho maybe bind-map has a good reason to do that.
Does anyone know something about that?


        Stefan

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

From: "Aaron Jensen" <aaronjensen <at> gmail.com>
To: "Stefan Monnier" <monnier <at> iro.umontreal.ca>
Cc: Jonas Bernoulli <jonas <at> bernoul.li>, 79305 <at> debbugs.gnu.org,
 Sean Whitton <spwhitton <at> spwhitton.name>
Subject: Re: bug#79305: 31.0.50; MODE-set-explicitly change caused
 regressions in bind-map
Date: Fri, 29 Aug 2025 16:23:31 +0000

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

On Fri, Aug 29, 2025 at 7:43 AM, Stefan Monnier < monnier <at> iro.umontreal.ca > wrote:

> 
> 
>> 
>> 
>> bind-map shouldn't use an internal variable like that.
>> 
>> 
>> 
> 
> 
> 
> +1, tho maybe bind-map has a good reason to do that. Does anyone know
> something about that?
> 
> 
> 
> 

It was in a commit with this message:

Fix evil-local-mode-hook logic

Can't be sure that the override modes are enabled before this hook is

run so we check if the global mode is enabled and if the local mode is

set explicitly in a prior hook (presumably a major mode hook).

https://github.com/justbur/emacs-bind-map/commit/89747f7240e5f51084fd94aad502d67f426e03b4

[Message part 2 (text/html, inline)]

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: "Aaron Jensen" <aaronjensen <at> gmail.com>
Cc: Jonas Bernoulli <jonas <at> bernoul.li>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, 79305 <at> debbugs.gnu.org
Subject: Re: bug#79305: 31.0.50; MODE-set-explicitly change caused
 regressions in bind-map
Date: Sun, 31 Aug 2025 16:23:12 +0100

Hello,

On Fri 29 Aug 2025 at 04:23pm GMT, Aaron Jensen wrote:

> On Fri, Aug 29, 2025 at 7:43 AM, Stefan Monnier <monnier <at> iro.umontreal.ca>
> wrote:
>
>  bind-map shouldn't use an internal variable like that.
>
>  +1, tho maybe bind-map has a good reason to do that. Does anyone know
>  something about that?
>
> It was in a commit with this message:
>
> Fix evil-local-mode-hook logic
> Can't be sure that the override modes are enabled before this hook is
> run so we check if the global mode is enabled and if the local mode is
> set explicitly in a prior hook (presumably a major mode hook).
>
> https://github.com/justbur/emacs-bind-map/commit/89747f7240e5f51084fd94aad502d67f426e03b4

Thanks for the link.  Unfortunately it seems like it would take a lot of
evil-mode knowledge to really know what's going on there.

Let me ask about the original purpose of the -set-explicitly machinery.
The comments say that the idea is that if the major mode hook has
(global-foo-mode -1), then our hook in after-change-major-mode-hook
won't undo that.

Major mode hooks are generally for the user.  So the idea is that this
is primarily a way for the user to disable the global minor mode in
particular major modes.  Right?

It looks to me that what emacs-bind-map is trying to use -set-explicitly
for is not that, but something about hook ordering.  So it's using it
for some other purpose, so it is probably using the wrong mechanism.

I think therefore in the absence of more information on the evil-mode
stuff, we should go ahead with restoring the variable but marking it as
obsolete.

-- 
Sean Whitton

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

From: "Aaron Jensen" <aaronjensen <at> gmail.com>
To: "Sean Whitton" <spwhitton <at> spwhitton.name>
Cc: Jonas Bernoulli <jonas <at> bernoul.li>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, 79305 <at> debbugs.gnu.org
Subject: Re: bug#79305: 31.0.50; MODE-set-explicitly change caused
 regressions in bind-map
Date: Sun, 31 Aug 2025 18:21:50 +0000

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

Hi Sean,

I believe it's using it only to determine whether or not to apply a key map to a minor mode. Specifically, it's attempting to detect the state when the global minor mode is enabled but that it is disabled explicitly in the given buffer. I have no idea why it doesn't just look at the value of the mode variable, which, as far as I understand it, would be made buffer local and nil in that same case. There must be some circumstance where that variable will not yet be set or buffer local and would have led to false indications.

Without the original author or specific tests for that scenario, I couldn't say anything for sure. I'd be fine with your proposal to restore the variable and mark it obsolete. I'm not sure that the original author of bind-map is very active anymore. I can update this bug if I hear anything from bind-map folks.

Thanks,

Aaron

On Sun, Aug 31, 2025 at 8:23 AM, Sean Whitton < spwhitton <at> spwhitton.name > wrote:

> 
> 
> 
> Hello,
> 
> 
> 
> On Fri 29 Aug 2025 at 04:23pm GMT, Aaron Jensen wrote:
> 
> 
>> 
>> 
>> On Fri, Aug 29 , 2025 at 7:43 AM, Stefan Monnier < monnier@ iro. umontreal.
>> ca ( monnier <at> iro.umontreal.ca ) > wrote:
>> 
>> 
>> 
>> bind-map shouldn't use an internal variable like that.
>> 
>> 
>> 
>> +1, tho maybe bind-map has a good reason to do that. Does anyone know
>> something about that?
>> 
>> 
>> 
>> It was in a commit with this message:
>> 
>> 
>> 
>> Fix evil-local-mode-hook logic
>> Can't be sure that the override modes are enabled before this hook is run
>> so we check if the global mode is enabled and if the local mode is set
>> explicitly in a prior hook (presumably a major mode hook).
>> 
>> 
>> 
>> https:/ / github. com/ justbur/ emacs-bind-map/ commit/ 89747f7240e5f51084fd94aad502d67f426e03b4
>> (
>> https://github.com/justbur/emacs-bind-map/commit/89747f7240e5f51084fd94aad502d67f426e03b4
>> )
>> 
>> 
> 
> 
> 
> Thanks for the link. Unfortunately it seems like it would take a lot of
> evil-mode knowledge to really know what's going on there.
> 
> 
> 
> Let me ask about the original purpose of the -set-explicitly machinery.
> The comments say that the idea is that if the major mode hook has
> (global-foo-mode -1), then our hook in after-change-major-mode-hook won't
> undo that.
> 
> 
> 
> Major mode hooks are generally for the user. So the idea is that this is
> primarily a way for the user to disable the global minor mode in
> particular major modes. Right?
> 
> 
> 
> It looks to me that what emacs-bind-map is trying to use -set-explicitly
> for is not that, but something about hook ordering. So it's using it for
> some other purpose, so it is probably using the wrong mechanism.
> 
> 
> 
> I think therefore in the absence of more information on the evil-mode
> stuff, we should go ahead with restoring the variable but marking it as
> obsolete.
> 
> 
> 
> --
> Sean Whitton
> 
> 
>

[Message part 2 (text/html, inline)]

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: Jonas Bernoulli <jonas <at> bernoul.li>, 79305 <at> debbugs.gnu.org,
 Aaron Jensen <aaronjensen <at> gmail.com>, Justin Burkett <justin <at> burkett.cc>
Subject: Re: bug#79305: 31.0.50; MODE-set-explicitly change caused
 regressions in bind-map
Date: Mon, 01 Sep 2025 00:49:48 -0400

>> bind-map shouldn't use an internal variable like that.
> +1, tho maybe bind-map has a good reason to do that.
> Does anyone know something about that?

After spending some time looking at the code, its history, and the
corresponding doc, my conclusion is that `bind-map`s code was probably
incorrect already with older Emacsen (just in different ways) and its
intended behavior is far from clear, so I think it's best to leave this
as a WONTFIX and let `bind-map`s authors figure out what to do on
their side (tho I'd be happy to help them figure that out).

The best patch I could come up with is the one below.


        Stefan


diff --git a/bind-map.el b/bind-map.el
index 41e6e5b5f0..204748efe8 100644
--- a/bind-map.el
+++ b/bind-map.el
@@ -171,19 +171,17 @@ be activated.")
          (when properties (pop properties)))))
 
 (defun bind-map-evil-local-mode-hook ()
-  "Called to activate local state maps in a buffer."
+  "Activate local state maps in a buffer." ;; FIXME: Which buffer?
   ;; format is (OVERRIDE-MODE STATE KEY DEF)
   (dolist (entry bind-map-evil-local-bindings)
     (let* ((map (intern (format "evil-%s-state-local-map" (nth 1 entry))))
            (mode (nth 0 entry))
-           (global-mode (intern (format "global-%s" (nth 0 entry))))
-           (set-explicitly (intern (format "%s-set-explicitly" mode))))
-      (when (and (boundp global-mode) (boundp mode)
-                 (boundp set-explicitly) (boundp map)
+           ;; FIXME: Why do we care about an associated global mode?
+           (global-mode (intern (format "global-%s" mode))))
+      (when (and (boundp global-mode) (boundp mode) (boundp map)
                  (keymapp (symbol-value map))
                  (symbol-value global-mode)
-                 (not (and (symbol-value set-explicitly)
-                           (null (symbol-value mode)))))
+                 (symbol-value mode))
         (define-key (symbol-value map) (nth 2 entry) (nth 3 entry))))))
 (add-hook 'evil-local-mode-hook 'bind-map-evil-local-mode-hook)
 

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

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Jonas Bernoulli <jonas <at> bernoul.li>, 79305 <at> debbugs.gnu.org,
 Aaron Jensen <aaronjensen <at> gmail.com>, Justin Burkett <justin <at> burkett.cc>
Subject: Re: bug#79305: 31.0.50; MODE-set-explicitly change caused
 regressions in bind-map
Date: Mon, 01 Sep 2025 09:43:21 +0100

Hello,

On Mon 01 Sep 2025 at 12:49am -04, Stefan Monnier wrote:

> After spending some time looking at the code, its history, and the
> corresponding doc, my conclusion is that `bind-map`s code was probably
> incorrect already with older Emacsen (just in different ways) and its
> intended behavior is far from clear, so I think it's best to leave this
> as a WONTFIX and let `bind-map`s authors figure out what to do on
> their side (tho I'd be happy to help them figure that out).

You don't think we should even restore it and mark it as obsolete?

Thanks for looking into it btw.

-- 
Sean Whitton

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: Jonas Bernoulli <jonas <at> bernoul.li>, 79305 <at> debbugs.gnu.org,
 Aaron Jensen <aaronjensen <at> gmail.com>, Justin Burkett <justin <at> burkett.cc>
Subject: Re: bug#79305: 31.0.50; MODE-set-explicitly change caused
 regressions in bind-map
Date: Mon, 01 Sep 2025 11:42:08 -0400

>> After spending some time looking at the code, its history, and the
>> corresponding doc, my conclusion is that `bind-map`s code was probably
>> incorrect already with older Emacsen (just in different ways) and its
>> intended behavior is far from clear, so I think it's best to leave this
>> as a WONTFIX and let `bind-map`s authors figure out what to do on
>> their side (tho I'd be happy to help them figure that out).
> You don't think we should even restore it and mark it as obsolete?

Since I believe bind-map's code was only half-working to begin with: no,
I don't think it's worth the trouble.  It would just help them
muddle through.  I'd rather help them fix their code for good.


        Stefan

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

From: "Aaron Jensen" <aaronjensen <at> gmail.com>
To: "Stefan Monnier" <monnier <at> iro.umontreal.ca>
Cc: Justin Burkett <justin <at> burkett.cc>, Jonas Bernoulli <jonas <at> bernoul.li>,
 79305 <at> debbugs.gnu.org, Sean Whitton <spwhitton <at> spwhitton.name>
Subject: Re: bug#79305: 31.0.50; MODE-set-explicitly change caused
 regressions in bind-map
Date: Mon, 01 Sep 2025 16:31:13 +0000

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

It's my understanding that the check for set-explicitly is done because given where this hook runs, it's possible that the mode variable is not yet initialized, which means that even though it eventually will be, and thus could be relied on, it may not be. Therefore, bind-map relies on similar logic as the minor mode itself to determine whether or not the minor mode *will eventually* be enabled. It seems like your proposed patch to bind-map would be subject to this "hook race".

Again, this is just an informed guess as I haven't set up the conditions to reproduce it yet.

I have extracted the relevant bind-map code to my own library that depended on it:

https://github.com/aaronjensen/emacs-leader-key/blob/master/leader-key.el#L109

Currently, it still relies on set-explicitly (accepting both forms), but if there's a way that we can get it to not I'd be happy to try it out.

Aaron

On Mon, Sep 01, 2025 at 8:42 AM, Stefan Monnier < monnier <at> iro.umontreal.ca > wrote:

> 
> 
>> 
>>> 
>>> 
>>> After spending some time looking at the code, its history, and the
>>> corresponding doc, my conclusion is that `bind-map`s code was probably
>>> incorrect already with older Emacsen (just in different ways) and its
>>> intended behavior is far from clear, so I think it's best to leave this as
>>> a WONTFIX and let `bind-map`s authors figure out what to do on their side
>>> (tho I'd be happy to help them figure that out).
>>> 
>>> 
>> 
>> 
>> 
>> You don't think we should even restore it and mark it as obsolete?
>> 
>> 
> 
> 
> 
> Since I believe bind-map's code was only half-working to begin with: no, I
> don't think it's worth the trouble. It would just help them muddle
> through. I'd rather help them fix their code for good.
> 
> 
> 
> Stefan
> 
> 
>

[Message part 2 (text/html, inline)]

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

From: "Aaron Jensen" <aaronjensen <at> gmail.com>
To: "Stefan Monnier" <monnier <at> iro.umontreal.ca>
Cc: Justin Burkett <justin <at> burkett.cc>, Jonas Bernoulli <jonas <at> bernoul.li>,
 79305 <at> debbugs.gnu.org, Sean Whitton <spwhitton <at> spwhitton.name>
Subject: Re: bug#79305: 31.0.50; MODE-set-explicitly change caused
 regressions in bind-map
Date: Mon, 01 Sep 2025 17:20:39 +0000

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

The attached demonstrates the problem, I believe.

Aaron

On Mon, Sep 01, 2025 at 9:31 AM, Aaron Jensen < aaronjensen <at> gmail.com > wrote:

> 
> It's my understanding that the check for set-explicitly is done because
> given where this hook runs, it's possible that the mode variable is not
> yet initialized, which means that even though it eventually will be, and
> thus could be relied on, it may not be. Therefore, bind-map relies on
> similar logic as the minor mode itself to determine whether or not the
> minor mode *will eventually* be enabled. It seems like your proposed patch
> to bind-map would be subject to this "hook race".
> 
> 
> 
> Again, this is just an informed guess as I haven't set up the conditions
> to reproduce it yet.
> 
> 
> 
> I have extracted the relevant bind-map code to my own library that
> depended on it:
> 
> 
> 
> https:/ / github. com/ aaronjensen/ emacs-leader-key/ blob/ master/ leader-key.
> el#L109 (
> https://github.com/aaronjensen/emacs-leader-key/blob/master/leader-key.el#L109
> )
> 
> 
> 
> Currently, it still relies on set-explicitly (accepting both forms), but
> if there's a way that we can get it to not I'd be happy to try it out.
> 
> 
> 
> 
> Aaron
> 
> 
> 
> On Mon, Sep 01, 2025 at 8:42 AM, Stefan Monnier < monnier@ iro. umontreal.
> ca ( monnier <at> iro.umontreal.ca ) > wrote:
> 
>> 
>>> 
>>>> 
>>>> 
>>>> After spending some time looking at the code, its history, and the
>>>> corresponding doc, my conclusion is that `bind-map`s code was probably
>>>> incorrect already with older Emacsen (just in different ways) and its
>>>> intended behavior is far from clear, so I think it's best to leave this as
>>>> a WONTFIX and let `bind-map`s authors figure out what to do on their side
>>>> (tho I'd be happy to help them figure that out).
>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> You don't think we should even restore it and mark it as obsolete?
>>> 
>>> 
>> 
>> 
>> 
>> Since I believe bind-map's code was only half-working to begin with: no, I
>> don't think it's worth the trouble. It would just help them muddle
>> through. I'd rather help them fix their code for good.
>> 
>> 
>> 
>> Stefan
>> 
>> 
>> 
> 
>

[Message part 2 (text/html, inline)]

[repro-evil-local-override-race.el (application/octet-stream, attachment)]

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

From: "Aaron Jensen" <aaronjensen <at> gmail.com>
To: "Stefan Monnier" <monnier <at> iro.umontreal.ca>
Cc: Justin Burkett <justin <at> burkett.cc>, Jonas Bernoulli <jonas <at> bernoul.li>,
 79305 <at> debbugs.gnu.org, Sean Whitton <spwhitton <at> spwhitton.name>
Subject: Re: bug#79305: 31.0.50; MODE-set-explicitly change caused
 regressions in bind-map
Date: Tue, 02 Sep 2025 05:48:38 +0000

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

I attempted to address the issue using different Evil primitives. I opened a PR with bind-map. I can't say for certain that it addresses every concern, but I'm not having any problems with it so far.

https://github.com/justbur/emacs-bind-map/pull/13

Aaron

On Mon, Sep 01, 2025 at 10:20 AM, Aaron Jensen < aaronjensen <at> gmail.com > wrote:

> 
> The attached demonstrates the problem, I believe.
> 
> 
> 
> 
> Aaron
> 
> 
> 
> On Mon, Sep 01, 2025 at 9:31 AM, Aaron Jensen < aaronjensen@ gmail. com (
> aaronjensen <at> gmail.com ) > wrote:
> 
>> It's my understanding that the check for set-explicitly is done because
>> given where this hook runs, it's possible that the mode variable is not
>> yet initialized, which means that even though it eventually will be, and
>> thus could be relied on, it may not be. Therefore, bind-map relies on
>> similar logic as the minor mode itself to determine whether or not the
>> minor mode *will eventually* be enabled. It seems like your proposed patch
>> to bind-map would be subject to this "hook race".
>> 
>> 
>> 
>> Again, this is just an informed guess as I haven't set up the conditions
>> to reproduce it yet.
>> 
>> 
>> 
>> I have extracted the relevant bind-map code to my own library that
>> depended on it:
>> 
>> 
>> 
>> https:/ / github. com/ aaronjensen/ emacs-leader-key/ blob/ master/ leader-key.
>> el#L109 (
>> https://github.com/aaronjensen/emacs-leader-key/blob/master/leader-key.el#L109
>> )
>> 
>> 
>> 
>> Currently, it still relies on set-explicitly (accepting both forms), but
>> if there's a way that we can get it to not I'd be happy to try it out.
>> 
>> 
>> 
>> 
>> Aaron
>> 
>> 
>> 
>> On Mon, Sep 01, 2025 at 8:42 AM, Stefan Monnier < monnier@ iro. umontreal.
>> ca ( monnier <at> iro.umontreal.ca ) > wrote:
>> 
>>> 
>>>> 
>>>>> 
>>>>> 
>>>>> After spending some time looking at the code, its history, and the
>>>>> corresponding doc, my conclusion is that `bind-map`s code was probably
>>>>> incorrect already with older Emacsen (just in different ways) and its
>>>>> intended behavior is far from clear, so I think it's best to leave this as
>>>>> a WONTFIX and let `bind-map`s authors figure out what to do on their side
>>>>> (tho I'd be happy to help them figure that out).
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> You don't think we should even restore it and mark it as obsolete?
>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> Since I believe bind-map's code was only half-working to begin with: no, I
>>> don't think it's worth the trouble. It would just help them muddle
>>> through. I'd rather help them fix their code for good.
>>> 
>>> 
>>> 
>>> Stefan
>>> 
>>> 
>>> 
>> 
>> 
> 
>

[Message part 2 (text/html, inline)]

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: "Aaron Jensen" <aaronjensen <at> gmail.com>
Cc: Justin Burkett <justin <at> burkett.cc>, Jonas Bernoulli <jonas <at> bernoul.li>,
 79305 <at> debbugs.gnu.org, Sean Whitton <spwhitton <at> spwhitton.name>
Subject: Re: bug#79305: 31.0.50; MODE-set-explicitly change caused
 regressions in bind-map
Date: Wed, 03 Sep 2025 18:43:12 -0400

> ;; Common sequence for both tests (identical order):
> ;; - New buffer
> ;; - Do NOT touch the per-buffer mode var (it is naturally nil here)
> ;; - Enable Evil locally (hook fires while per-buffer mode is still nil)
>
> ;; Scenario 1: Broken path misses install due to requiring buffer-local mode
> (remove-hook 'evil-local-mode-hook #'repro-broken-install)
> (remove-hook 'evil-local-mode-hook #'repro-fixed-install)
> (add-hook 'evil-local-mode-hook #'repro-broken-install)
>
> (with-temp-buffer
>   (evil-local-mode 1)
>   (repro-log "BROKEN installed? %S" (repro-installed-p)))

I don't understand the intention behind this test: a temp buffer is not
expected to be exposed to the user, so the specific way `evil-mode`
behaves in it doesn't seem very relevant.

Also, the `repro-override-mode` is not enabled in that buffer, so IIUC
the `repro-key` binding should not be active, so it would be a bug if
(repro-installed-p) to returned non-nil, right?


        Stefan

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

From: "Aaron Jensen" <aaronjensen <at> gmail.com>
To: "Stefan Monnier" <monnier <at> iro.umontreal.ca>
Cc: Justin Burkett <justin <at> burkett.cc>, Jonas Bernoulli <jonas <at> bernoul.li>,
 79305 <at> debbugs.gnu.org, Sean Whitton <spwhitton <at> spwhitton.name>
Subject: Re: bug#79305: 31.0.50; MODE-set-explicitly change caused
 regressions in bind-map
Date: Wed, 03 Sep 2025 23:00:51 +0000

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

On Wed, Sep 03, 2025 at 3:43 PM, Stefan Monnier < monnier <at> iro.umontreal.ca > wrote:

> 
> 
>> 
>> 
>> ;; Common sequence for both tests (identical order):
>> ;; - New buffer
>> ;; - Do NOT touch the per-buffer mode var (it is naturally nil here)
>> ;; - Enable Evil locally (hook fires while per-buffer mode is still nil)
>> 
>> 
>> 
>> ;; Scenario 1: Broken path misses install due to requiring buffer-local
>> mode
>> (remove-hook 'evil-local-mode-hook #'repro-broken-install)
>> (remove-hook 'evil-local-mode-hook #'repro-fixed-install)
>> (add-hook 'evil-local-mode-hook #'repro-broken-install)
>> 
>> 
>> 
>> (with-temp-buffer
>> (evil-local-mode 1)
>> (repro-log "BROKEN installed? %S" (repro-installed-p)))
>> 
>> 
> 
> 
> 
> I don't understand the intention behind this test: a temp buffer is not
> expected to be exposed to the user, so the specific way `evil-mode`
> behaves in it doesn't seem very relevant.
> 
> 
> 
> 

You can try it interactively, but the steps are a little different. If you comment everything below the scenario 1 hooks and then run:

emacs -Q -l scripts/repro-evil-local-override-race.el

Then M-x evil-mode

Then C-x C-f somefile

Then SPC x

It will not invoke the binding.

If you then comment the Scenario 1 hooks and comment the Scenario 2 hooks and try the same thing, SPC x will be bound.

> 
> 
> 
> Also, the `repro-override-mode` is not enabled in that buffer, so IIUC the
> `repro-key` binding should not be active, so it would be a bug if
> 
> 
> 
> (repro-installed-p) to returned non-nil, right?
> 
> 
> 
> 

It's globalized and is enabled via:

(global-repro-override-mode 1)

Globalized minor modes are the problematic thing here.

Aaron

[Message part 2 (text/html, inline)]

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: "Aaron Jensen" <aaronjensen <at> gmail.com>
Cc: Justin Burkett <justin <at> burkett.cc>, Jonas Bernoulli <jonas <at> bernoul.li>,
 79305 <at> debbugs.gnu.org, Sean Whitton <spwhitton <at> spwhitton.name>
Subject: Re: bug#79305: 31.0.50; MODE-set-explicitly change caused
 regressions in bind-map
Date: Wed, 03 Sep 2025 23:07:49 -0400

> You can try it interactively, but the steps are a little different. If you
> comment everything below the scenario 1 hooks and then run:
>
> emacs -Q -l scripts/repro-evil-local-override-race.el
>
> Then M-x evil-mode
>
> Then C-x C-f somefile
>
> Then SPC x
>
> It will not invoke the binding.
>
> If you then comment the Scenario 1 hooks and comment the Scenario 2 hooks
> and try the same thing, SPC x will be bound.

I don't understand enough of what these things mean to know what is
supposed to be the right behavior (and why).

Is this `SPC x` key supposed to be bound if and only if the
`repro-override-mode` is enabled?

>> Also, the `repro-override-mode` is not enabled in that buffer, so IIUC the
>> `repro-key` binding should not be active, so it would be a bug if
>> 
>> (repro-installed-p) to returned non-nil, right?
>
> It's globalized and is enabled via:
>
> (global-repro-override-mode 1)

Right, but that just means the buffer-local mode should be enabled in
some buffers according to some rule.  In your tests, you run the tests
in a temp buffer where the globalized mode hasn't even had a chance to
enable the buffer-local minor mode, so the buffer-local minor is off.


        Stefan

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

From: "Aaron Jensen" <aaronjensen <at> gmail.com>
To: "Stefan Monnier" <monnier <at> iro.umontreal.ca>
Cc: Justin Burkett <justin <at> burkett.cc>, Jonas Bernoulli <jonas <at> bernoul.li>,
 79305 <at> debbugs.gnu.org, Sean Whitton <spwhitton <at> spwhitton.name>
Subject: Re: bug#79305: 31.0.50; MODE-set-explicitly change caused
 regressions in bind-map
Date: Thu, 04 Sep 2025 03:38:53 +0000

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

On Wed, Sep 03, 2025 at 8:07 PM, Stefan Monnier < monnier <at> iro.umontreal.ca > wrote:

> 
> 
>> 
>> 
>> You can try it interactively, but the steps are a little different. If you
>> comment everything below the scenario 1 hooks and then run:
>> 
>> 
>> 
>> 
>> emacs -Q -l scripts/repro-evil-local-override-race.el
>> 
>> 
>> 
>> 
>> Then M-x evil-mode
>> 
>> 
>> 
>> 
>> Then C-x C-f somefile
>> 
>> 
>> 
>> 
>> Then SPC x
>> 
>> 
>> 
>> 
>> It will not invoke the binding.
>> 
>> 
>> 
>> 
>> If you then comment the Scenario 1 hooks and comment the Scenario 2 hooks
>> and try the same thing, SPC x will be bound.
>> 
>> 
>> 
> 
> 
> 
> I don't understand enough of what these things mean to know what is
> supposed to be the right behavior (and why).
> 
> 
> 
> 
> Is this `SPC x` key supposed to be bound if and only if the
> `repro-override-mode` is enabled?
> 
> 
> 

Yes. This is how bind-map works. It adds to `evil-normal-state-local-map`, which is a buffer local key map. It does this in response to evil-local-mode-hook, which, when evil-mode is enabled, will trigger in most buffers, and when it does, if the globalized minor mode being considered has not yet been initialized (as you mention below) then it cannot simply use the mode variable to determine if it's enabled. That's the inherent ordering problem. There are effectively two globalized minor modes that are order dependent. The work around present in bind-map (and eliminated in your proposed patch to bind-map) is to check to see if the globalized minor mode *will* be enabled eventually by using the same criteria used to enable it later.

To be clear, I think this is a flaw in bind-map. I shared the repro before I figured out an alternative that does not have this limitation and is more in line with how evil seems to work. In other words, you may feel free to disregard this repro and proceed with closing this bug if you like. I don't know if bind-map will be updated or not, but it does seem like it's not essential for it to use to the set-explicitly internal variable.

Aaron

[Message part 2 (text/html, inline)]

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: "Aaron Jensen" <aaronjensen <at> gmail.com>
Cc: Justin Burkett <justin <at> burkett.cc>, Jonas Bernoulli <jonas <at> bernoul.li>,
 79305 <at> debbugs.gnu.org, Sean Whitton <spwhitton <at> spwhitton.name>
Subject: Re: bug#79305: 31.0.50; MODE-set-explicitly change caused
 regressions in bind-map
Date: Thu, 04 Sep 2025 00:25:18 -0400

> Yes.  This is how bind-map works.

[ My questions are about how it *should* work rather than how it works.  ]

> It adds to `evil-normal-state-local-map`,
> which is a buffer local key map. It does this in response
> to evil-local-mode-hook, which, when evil-mode is enabled, will trigger in
> most buffers, and when it does, if the globalized minor mode being
> considered has not yet been initialized (as you mention below) then it

[ In your examples, while the globalized major mode has not been
  initialized, it *will not* be initialized later either, AFAICT.  ]

> cannot simply use the mode variable to determine if it's enabled.

Another way to look at the problem: when the minor mode is enabled or
disabled (which can happen at any time), which part of bind-map reacts
to update `evil-normal-state-local-map`?

> To be clear, I think this is a flaw in bind-map. I shared the repro before
> I figured out an alternative that does not have this limitation and is more
> in line with how evil seems to work. In other words, you may feel free to
> disregard this repro and proceed with closing this bug if you like.  I don't
> know if bind-map will be updated or not, but it does seem like it's not
> essential for it to use to the set-explicitly internal variable.

I think you're reaching the same conclusion I had reached, indeed: the
approach used currently in bind-map is flawed and works only in
some/most circumstances.


        Stefan

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

From: "Aaron Jensen" <aaronjensen <at> gmail.com>
To: "Stefan Monnier" <monnier <at> iro.umontreal.ca>
Cc: Justin Burkett <justin <at> burkett.cc>, Jonas Bernoulli <jonas <at> bernoul.li>,
 79305 <at> debbugs.gnu.org, Sean Whitton <spwhitton <at> spwhitton.name>
Subject: Re: bug#79305: 31.0.50; MODE-set-explicitly change caused
 regressions in bind-map
Date: Thu, 04 Sep 2025 04:46:34 +0000

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

On Wed, Sep 03, 2025 at 9:25 PM, Stefan Monnier < monnier <at> iro.umontreal.ca > wrote:

> 
> 
>> 
>> 
>> Yes. This is how bind-map works.
>> 
>> 
>> 
> 
> 
> 
> [ My questions are about how it *should* work rather than how it works. ]
> 
> 
> 
> 

Ah, then yeah, it should ideally add/remove bindings in response to any minor mode being enabled/disabled at any time as you say below. It doesn't work that way now AFAICT.

> 
> 
> 
> 
> 
> 
> 
>> 
>> 
>> It adds to `evil-normal-state-local-map`,
>> which is a buffer local key map. It does this in response to
>> evil-local-mode-hook, which, when evil-mode is enabled, will trigger in
>> most buffers, and when it does, if the globalized minor mode being
>> considered has not yet been initialized (as you mention below) then it
>> 
>> 
> 
> 
> 
> [ In your examples, while the globalized major mode has not been
> initialized, it *will not* be initialized later either, AFAICT. ]
> 
> 
> 
> 

Got it, that is confusing. In any case, the manual example I gave that requires enabling evil-mode displays the same problematic behavior with the considered patch and does work with the existing bind-map code, but as you get to below… that probably doesn't matter. It's insufficient.

> 
> 
> 
> 
> 
> 
> 
>> 
>> 
>> cannot simply use the mode variable to determine if it's enabled.
>> 
>> 
>> 
> 
> 
> 
> Another way to look at the problem: when the minor mode is enabled or
> disabled (which can happen at any time), which part of bind-map reacts to
> update `evil-normal-state-local-map`?
> 
> 
> 
>> 
>> 
>> To be clear, I think this is a flaw in bind-map. I shared the repro before
>> I figured out an alternative that does not have this limitation and is
>> more in line with how evil seems to work. In other words, you may feel
>> free to disregard this repro and proceed with closing this bug if you
>> like. I don't know if bind-map will be updated or not, but it does seem
>> like it's not essential for it to use to the set-explicitly internal
>> variable.
>> 
>> 
>> 
> 
> 
> 
> I think you're reaching the same conclusion I had reached, indeed: the
> approach used currently in bind-map is flawed and works only in some/most
> circumstances.
> 
> 
> 
> 

Good deal. Thank you for helping work through this.

Aaron

> 
> 
> 
> 
> 
> 
> 
> 
> Stefan
> 
> 
> 
>

[Message part 2 (text/html, inline)]

Previous Next

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