GNU bug report logs - #76156
31.0.50; Wrong STATE when customizing allout-command-prefix

Previous Next

Full log

View this message in rfc822 format

From: Mauro Aranda <maurooaranda <at> gmail.com>
To: "Basil L. Contovounesios" <basil <at> contovou.net>
Cc: 76156 <at> debbugs.gnu.org
Subject: bug#76156: 31.0.50; Wrong STATE when customizing allout-command-prefix
Date: Sat, 15 Feb 2025 09:37:46 -0300

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

Mauro Aranda <maurooaranda <at> gmail.com> writes:

> "Basil L. Contovounesios" <basil <at> contovou.net> writes:
>
>> Mauro Aranda [2025-02-13 21:22 -0300] wrote:
>>
>>> "Basil L. Contovounesios" <basil <at> contovou.net> writes:
>>>> Mauro Aranda [2025-02-09 08:57 -0300] wrote:
>>>>> Mauro Aranda <maurooaranda <at> gmail.com> writes:
>>>>>
>>>>>> After emacs -Q:
>>>>>> (require 'allout)
>>>>>> M-x customize-option RET allout-command-prefix
>>>>>>
>>>>>> The Customize buffer shows up, with STATE being:
>>>>>> EDITED, shown value does not take effect until you set or save it.
>>>>>>
>>>>>> That's wrong, it should say STANDARD.
>>>>
>>>> Agreed, but this must be common to all key-sequence user options,
>     right?
>>>>
>>>> I see the same state with:
>>>>
>>>> - cua-rectangle-mark-key
>>>> - flyspell-auto-correct-binding
>>>> - footnote-prefix
>>>> - gud-key-prefix
>>>> - hide-ifdef-mode-prefix-key
>>>> - outline-minor-mode-prefix
>>>> - viper-toggle-key
>>>
>>> Right.  Thanks for finding those.
>>>
>>>> So I think this was a regression somewhere in Emacs 27;
>>>> the startup state looks as expected in Emacs versions 24 through 26.
>>>
>>> I can't try Emacs 26, sadly.  But I take your word. Problem is, with
>>> the widget being obsolete, there's no much incentive to go chasing the
>>> cause, at least for me.
>>
>> I asked Git, so you can give me my word back ;).
>>
>>   283fd5f2f6f3fa1f650c5a77f9e3587faddd6881 is the first bad commit
>>   Author: Mauro Aranda <maurooaranda <at> gmail.com>
>>   Date:   2019-09-27 18:06:36 +0200
>>
>>   Don't discard customizations in progress when adding comments
>  (Bug#5358)
>>
>> The bisect covered emacs-26.3..emacs-27.2.  In every step I checked the
>> state of viper-toggle-key, which has been a vector since 2005, and a
>> key-sequence since Emacs 25.
>>
>
> Thanks! I was looking into it, and wasn't sure if that was the culprit
> commit.
>
>> Starting with the 'bad' commit, the user option shows up as EDITED in
>> emacs -Q.  This is because default-value returns [(control ?z)], whereas
>> widget-value returns "^Z" in the function custom-variable-modified-p.
>
> Yes.  I'm trying to see if calling the :value-to-external on value
> is enough, but I think I'm running into the issue you mentioned:
> key-parse is dropping the trailing space, so no luck so far.

I came up with a fix for custom-variable-modified-p, in the attached
patch.

With the patch, all of these options show its state as STANDARD, which
is what should happen:
- allout-command-prefix
- cua-rectangle-mark-key
- flyspell-auto-correct-binding
- footnote-prefix
- gud-key-prefix
- hide-ifdef-mode-prefix-key
- outline-minor-mode-prefix
- viper-toggle-key

I've found that converting those to use the key widget instead is
potentially not backward compatible, and introduces too many
complications that I concluded it's not worth it, so I didn't pursue it
anymore.

I've done extensive testing on other types to avoid regressions, and
didn't find any.

[0001-Fix-comparison-of-current-values-for-the-key-sequenc.patch (text/x-patch, attachment)]

Previous Next

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