Subject: Re: bug#76156: 31.0.50; Wrong STATE when customizing allout-command-prefix

From: Mauro Aranda <[email-masked]>
Date: Fri, 14 Feb 2025 09:47:01 -0300

"Basil L. Contovounesios" <[email-masked]> writes:

 > Mauro Aranda [2025-02-13 21:22 -0300] wrote:
 >
 >> "Basil L. Contovounesios" <[email-masked]> writes:
 >>> Mauro Aranda [2025-02-09 08:57 -0300] wrote:
 >>>> Mauro Aranda <[email-masked]> 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 <[email-masked]>
 >   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.