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: Thu, 13 Feb 2025 21:22:23 -0300

"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.

>> The commit that introduced this is:
>>
>> commit f7c2fe3337bb5e5721d17f40f79dbc1275e17b0d
>> Author: Basil L. Contovounesios <basil <at> contovou.net>
>> Date:   Wed Feb 28 16:38:21 2024 +0100
>>
>>     Pacify some docstring control char warnings
>>
>>     Other instances are discussed in the following thread:
>> https://lists.gnu.org/r/emacs-devel/2024-02/msg00797.html
>>
>>     * lisp/allout.el (allout-command-prefix): Declare :type as
>>     key-sequence.  Mark up key sequences in docstring.
>>
>> The :type was changed from string to key-sequence, but not the value,
>
> Yes, I was trying to avoid changing the default value.

>> 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.

> - The manual entry for key-sequence links to
>   (info "(elisp) Key Sequences") which e.g. includes the text:
>
>     ‘"\C-xl"’ represents the key sequence ‘C-x l’
>
>   according to which I would (and did) interpret "\C-c " as also being a
>   key sequence.
>
> - widget-key-sequence-validate takes any string or vector.
>
> - widget-key-sequence-value-to-internal delegates to key-description,
>   which works as desired: (key-description "\C-c ") => "C-c SPC".
>
> - 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.

>> Furthermore, the key-sequence widget has been marked as obsolete since
>> 2022.
>
> Yes, at the time I probably thought that in the future someone would
> switch the remaining key-sequence user options to some other default
> format, but I didn't want to undertake that :).

Understandable :).  Maybe I'll give it a shot, but I don't know if it
can be backward compatible.

>> Because of compatibility, I recommend keeping the :type as string,
>> since other widgets are more restrictive.
>
> No objections from me, although the UI for strings representing keys
> leaves something to be desired :).

OK, so I'll try to convert these options to use the key widget.

Thanks for your response.

Previous Next

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