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

Previous Next

Full log

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.

Previous Next

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