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

Previous Next

Package: emacs;

Reported by: Aaron Jensen <aaronjensen <at> gmail.com>

Date: Sun, 24 Aug 2025 22:19:01 UTC

Severity: normal

Found in version 31.0.50

Full log


View this message in rfc822 format

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

This bug report was last modified 4 days ago.

Previous Next


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