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

Previous Next

Package: emacs;

Reported by: Mauro Aranda <maurooaranda <at> gmail.com>

Date: Sun, 9 Feb 2025 11:49:02 UTC

Severity: normal

Tags: patch

Found in version 31.0.50

Fixed in version 31.1

Done: Stefan Kangas <stefankangas <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: "Basil L. Contovounesios" <basil <at> contovou.net>
To: Mauro Aranda <maurooaranda <at> gmail.com>
Cc: 76156 <at> debbugs.gnu.org
Subject: bug#76156: 31.0.50; Wrong STATE when customizing allout-command-prefix
Date: Fri, 14 Feb 2025 13:34:42 +0100
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.

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.

>>> and the key-sequence widget requires another format for its value.
>> What format is that?
> A vector.  This has been the case for quite some time, I think.

That makes sense, but unfortunately it wasn't clear to me from its
documentation and usage in the wild.

>> - widget-key-sequence-value-to-external via key-parse/read-kbd-macro
>>   drops the trailing space (this surprised me), but this shouldn't give
>>   rise to the current issue, given it behaved the same in Emacs 26, and
>>   also given the other affected user options.
>
> This is the one that matters.  The value is "C-c SPC", and it doesn't
> match with [3 32].  But again, no incentive for me to touch that code,
> since we should be using either the key widget, or keeping it as a
> string.

Right.

Thanks,
-- 
Basil




This bug report was last modified 142 days ago.

Previous Next


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