GNU bug report logs - #30101
25.3; defcustom does not clear old :options when reevaluated

Previous Next

Package: emacs;

Reported by: Tim Landscheidt <tim <at> tim-landscheidt.de>

Date: Sat, 13 Jan 2018 22:16:02 UTC

Severity: minor

Tags: fixed

Found in version 25.3

Fixed in version 28.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 30101 in the body.
You can then email your comments to 30101 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#30101; Package emacs. (Sat, 13 Jan 2018 22:16:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Tim Landscheidt <tim <at> tim-landscheidt.de>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sat, 13 Jan 2018 22:16:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Tim Landscheidt <tim <at> tim-landscheidt.de>
To: bug-gnu-emacs <at> gnu.org
Subject: 25.3; defcustom does not clear old :options when reevaluated
Date: Sat, 13 Jan 2018 22:14:50 +0000
If one evaluates first:

| (defcustom tmp-test-variable2 nil
|   "A vowel."
|   :type 'alist
|   :options '("A" "F" "I" "O" "U"))

and then changes "F" to "E" and evaluates:

| (defcustom tmp-test-variable2 nil
|   "A vowel."
|   :type 'alist
|   :options '("A" "E" "I" "O" "U"))

the resulting customization page looks like:

| Hide Tmp Test Variable2:
| [ ] Key: E
|     Value: nil
| [ ] Key: A
|     Value: nil
| [ ] Key: F
|     Value: nil
| [ ] Key: I
|     Value: nil
| [ ] Key: O
|     Value: nil
| [ ] Key: U
|     Value: nil
| INS
|     State : STANDARD.
|    A vowel.
| Groups: Nil

i. e., it is the superset of the :options of the two calls.
This is unexpected and undocumented.

AFAICT, this behaviour stems from lisp/custom.el's:

| […]
|                 ((eq keyword :options)
|                  (if (get symbol 'custom-options)
|                      ;; Slow safe code to avoid duplicates.
|                      (mapc (lambda (option)
|                              (custom-add-option symbol option))
|                            value)
|                    ;; Fast code for the common case.
|                    (put symbol 'custom-options (copy-sequence value))))
| […]

which has not been substantially touched since the initial
revision (d543e20b611fc289b174aa82cab940d873a586ff).

Is there any harm in always putting the copied sequence un-
conditionally?

(Workaround: (put 'tmp-test-variable2 'custom-options nil).)




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#30101; Package emacs. (Sun, 14 Jan 2018 20:33:03 GMT) Full text and rfc822 format available.

Message #8 received at 30101 <at> debbugs.gnu.org (full text, mbox):

From: Tim Landscheidt <tim <at> tim-landscheidt.de>
To: 30101 <at> debbugs.gnu.org
Subject: Re: bug#30101: 25.3;
 defcustom does not clear old :options when reevaluated
Date: Sun, 14 Jan 2018 20:32:19 +0000
Further reading shows that this cumultative behaviour is
needed via custom-add-option by various files that enhance
the options of a different file's variables with it:

| [tim <at> passepartout ~/src/emacs]$ git grep custom-add-option -- \*.el
| lisp/calendar/diary-lib.el:(custom-add-option 'gnus-article-prepare-hook 'diary-from-outlook-gnus)
| lisp/custom.el:                      (custom-add-option symbol option))
| lisp/custom.el:(defun custom-add-option (symbol option)
| lisp/custom.el:(defalias 'custom-add-frequent-value 'custom-add-option)
| lisp/emacs-lisp/checkdoc.el:(custom-add-option 'emacs-lisp-mode-hook 'checkdoc-minor-mode)
| lisp/eshell/esh-mode.el:(custom-add-option 'eshell-pre-command-hook 'eshell-push-command-mark)
| lisp/eshell/esh-mode.el:(custom-add-option 'eshell-pre-command-hook 'eshell-push-command-mark)
| lisp/eshell/esh-mode.el:(custom-add-option 'eshell-input-filter-functions 'eshell-kill-new)
| lisp/eshell/esh-mode.el:(custom-add-option 'eshell-output-filter-functions
| lisp/eshell/esh-mode.el:(custom-add-option 'eshell-output-filter-functions
| lisp/eshell/esh-mode.el:(custom-add-option 'eshell-output-filter-functions
| lisp/eshell/esh-mode.el:(custom-add-option 'eshell-output-filter-functions
| lisp/gnus/message.el:(custom-add-option 'message-setup-hook 'message-check-recipients)
| lisp/gnus/nnmail.el:(custom-add-option 'nnmail-prepare-incoming-header-hook
| lisp/simple.el:(custom-add-option 'text-mode-hook 'turn-on-auto-fill)
| lisp/textmodes/flyspell.el:(custom-add-option 'text-mode-hook 'turn-on-flyspell)
| [tim <at> passepartout ~/src/emacs]$

So this behaviour cannot be changed, but should be document-
ed.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#30101; Package emacs. (Mon, 15 Jan 2018 05:17:02 GMT) Full text and rfc822 format available.

Message #11 received at 30101 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Tim Landscheidt <tim <at> tim-landscheidt.de>
Cc: 30101 <at> debbugs.gnu.org
Subject: Re: bug#30101: 25.3;
 defcustom does not clear old :options when reevaluated
Date: Mon, 15 Jan 2018 07:16:06 +0200
> From: Tim Landscheidt <tim <at> tim-landscheidt.de>
> Date: Sun, 14 Jan 2018 20:32:19 +0000
> 
> So this behaviour cannot be changed, but should be document-
> ed.

Patches to document this will be welcome.

Thanks.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#30101; Package emacs. (Sat, 29 Aug 2020 15:12:01 GMT) Full text and rfc822 format available.

Message #14 received at 30101 <at> debbugs.gnu.org (full text, mbox):

From: Mauro Aranda <maurooaranda <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 30101 <at> debbugs.gnu.org, tim <at> tim-landscheidt.de
Subject: Re: bug#30101: 25.3;
 defcustom does not clear old :options when reevaluated
Date: Sat, 29 Aug 2020 12:11:07 -0300
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Tim Landscheidt <tim <at> tim-landscheidt.de>
>> Date: Sun, 14 Jan 2018 20:32:19 +0000
>>
>> So this behaviour cannot be changed, but should be document-
>> ed.
>
> Patches to document this will be welcome.
>
> Thanks.

I took a shot at it.  Please review.
[Message part 2 (text/html, inline)]
[0001-Improve-documentation-for-custom-options.patch (text/x-patch, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#30101; Package emacs. (Sat, 29 Aug 2020 15:42:02 GMT) Full text and rfc822 format available.

Message #17 received at 30101 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mauro Aranda <maurooaranda <at> gmail.com>
Cc: 30101 <at> debbugs.gnu.org, tim <at> tim-landscheidt.de
Subject: Re: bug#30101: 25.3;
 defcustom does not clear old :options when reevaluated
Date: Sat, 29 Aug 2020 18:41:24 +0300
> From: Mauro Aranda <maurooaranda <at> gmail.com>
> Date: Sat, 29 Aug 2020 12:11:07 -0300
> Cc: tim <at> tim-landscheidt.de, 30101 <at> debbugs.gnu.org
> 
> I took a shot at it.  Please review.

Thanks, I have a few comments.

> * doc/lispref/customize.texi (Defining Customization Variables):
                               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The name in parentheses should be the name of the node, not of the
section.

> +Re-evaluating a @code{defcustom} form of an already defined user
> +option does not clear the reasonable values added by previous
> +evaluations, or by calls to @code{custom-add-frequent-value}.  This
> +way, Lisp programs can add reasonable values for user options not yet
> +defined.

This doesn't emphasize the fact that you are talking about
reevaluation after changing the option's values.  Without that, this
text doesn't drive the point home.

Also, I'd suggest to drop the "reasonable" part, as it gets in the way
of understanding the important parts by distracting the reader to
think about what "reasonable" means in this context.

> --- a/lisp/custom.el
> +++ b/lisp/custom.el
> @@ -578,9 +578,14 @@ custom-add-dependencies
>  (defun custom-add-option (symbol option)
>    "To the variable SYMBOL add OPTION.
>  
> +Custom then presents OPTION to the user as a suggested member
> +for the value of SYMBOL.
> +
>  If SYMBOL's custom type is a hook, OPTION should be a hook member.
> -If SYMBOL's custom type is an alist, OPTION specifies a symbol
> -to offer to the user as a possible key in the alist.
> +If SYMBOL's custom type is an alist, OPTION specifies a possible key
> +in the alist.
> +Similarly, if SYMBOL's custom type is a plist, OPTION specifies
> +a possible name in the plist.
>  For other custom types, this has no effect."

I don't think I understand what this tries to accomplish, or how it is
relevant to the issue discussed here.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#30101; Package emacs. (Sat, 29 Aug 2020 16:18:02 GMT) Full text and rfc822 format available.

Message #20 received at 30101 <at> debbugs.gnu.org (full text, mbox):

From: Mauro Aranda <maurooaranda <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 30101 <at> debbugs.gnu.org, tim <at> tim-landscheidt.de
Subject: Re: bug#30101: 25.3;
 defcustom does not clear old :options when reevaluated
Date: Sat, 29 Aug 2020 13:17:18 -0300
[Message part 1 (text/plain, inline)]
Eli Zaretskii <eliz <at> gnu.org> writes:

>> * doc/lispref/customize.texi (Defining Customization Variables):
>                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> The name in parentheses should be the name of the node, not of the
> section.

Right, sorry.

>> +Re-evaluating a @code{defcustom} form of an already defined user
>> +option does not clear the reasonable values added by previous
>> +evaluations, or by calls to @code{custom-add-frequent-value}.  This
>> +way, Lisp programs can add reasonable values for user options not yet
>> +defined.
>
> This doesn't emphasize the fact that you are talking about
> reevaluation after changing the option's values.  Without that, this
> text doesn't drive the point home.

Then perhaps it makes sense to split the paragraph, and talk about that
when describing the :options keyword?  I did that in this new patch.

> Also, I'd suggest to drop the "reasonable" part, as it gets in the way
> of understanding the important parts by distracting the reader to
> think about what "reasonable" means in this context.

Fair enough.  Dropped it.

>> --- a/lisp/custom.el
>> +++ b/lisp/custom.el
>> @@ -578,9 +578,14 @@ custom-add-dependencies
>>  (defun custom-add-option (symbol option)
>>    "To the variable SYMBOL add OPTION.
>>
>> +Custom then presents OPTION to the user as a suggested member
>> +for the value of SYMBOL.
>> +
>>  If SYMBOL's custom type is a hook, OPTION should be a hook member.
>> -If SYMBOL's custom type is an alist, OPTION specifies a symbol
>> -to offer to the user as a possible key in the alist.
>> +If SYMBOL's custom type is an alist, OPTION specifies a possible key
>> +in the alist.
>> +Similarly, if SYMBOL's custom type is a plist, OPTION specifies
>> +a possible name in the plist.
>>  For other custom types, this has no effect."
>
> I don't think I understand what this tries to accomplish, or how it is
> relevant to the issue discussed here.

The docstring didn't mention what was the effect if SYMBOL was a plist,
so I thought I'd take the chance of improving the docstring for the
function that also affects the suggested values.  But maybe that can be
left for another patch, so I dropped it in this new one.

Thanks for reviewing, I hope this patch is better.
[Message part 2 (text/html, inline)]
[0001-Improve-documentation-for-custom-options.patch (text/x-patch, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#30101; Package emacs. (Tue, 01 Sep 2020 15:01:01 GMT) Full text and rfc822 format available.

Message #23 received at 30101 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Mauro Aranda <maurooaranda <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 30101 <at> debbugs.gnu.org, tim <at> tim-landscheidt.de
Subject: Re: bug#30101: 25.3; defcustom does not clear old :options when
 reevaluated
Date: Tue, 01 Sep 2020 17:00:33 +0200
Mauro Aranda <maurooaranda <at> gmail.com> writes:

> Thanks for reviewing, I hope this patch is better.

Looks good to me -- I've now applied it to Emacs 28 (with a minor
rewording for clarity).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Added tag(s) fixed. Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Tue, 01 Sep 2020 15:01:02 GMT) Full text and rfc822 format available.

bug marked as fixed in version 28.1, send any further explanations to 30101 <at> debbugs.gnu.org and Tim Landscheidt <tim <at> tim-landscheidt.de> Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Tue, 01 Sep 2020 15:01:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#30101; Package emacs. (Tue, 01 Sep 2020 20:24:02 GMT) Full text and rfc822 format available.

Message #30 received at 30101 <at> debbugs.gnu.org (full text, mbox):

From: Mauro Aranda <maurooaranda <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 30101 <at> debbugs.gnu.org
Subject: Re: bug#30101: 25.3;
 defcustom does not clear old :options when reevaluated
Date: Tue, 1 Sep 2020 17:23:25 -0300
[Message part 1 (text/plain, inline)]
Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Mauro Aranda <maurooaranda <at> gmail.com> writes:
>
>> Thanks for reviewing, I hope this patch is better.
>
> Looks good to me -- I've now applied it to Emacs 28 (with a minor
> rewording for clarity).

Thanks!
[Message part 2 (text/html, inline)]

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Wed, 30 Sep 2020 11:24:03 GMT) Full text and rfc822 format available.

This bug report was last modified 3 years and 180 days ago.

Previous Next


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