GNU bug report logs - #23926
defcustom with STANDARD=<non-constant-expression> gives confusing results

Previous Next

Full log

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

From: npostavs <at> users.sourceforge.net
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 23926 <at> debbugs.gnu.org
Subject: Re: bug#23926: defcustom with STANDARD=<non-pure-expression> gives
 confusing results
Date: Mon, 11 Jul 2016 23:26:25 -0400

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Either really save the original value, or don't call it the "original
>> value". We can't use "default value" because that's already used for
>> the non-buffer local value, unfortunately. I think "standard value"
>> could work, though Drew said it was unclear.
>
> Why change anything in the wording at all?  It won't really change
> what is being done, and won't prevent any confusion, because all this
> "standard", "original", "default" etc. are not well defined anyway.

I had a look at the docs; seems to me "standard" is used consistently,
so it makes sense to change to that.  Docstring of defcustom:

    STANDARD is an expression specifying the variable’s standard
    value.  It should not be quoted.  It is evaluated once by
    ‘defcustom’, and the value is assigned to SYMBOL if the variable
    is unbound.  The expression itself is also stored, so that
    Customize can re-evaluate it later to get the standard value.
    DOC is the variable documentation.

Elisp manual description of defcustom:

    The argument STANDARD is an expression that specifies the standard
    value for OPTION. ...

    The expression STANDARD can be evaluated at various other times,
    too—whenever the customization facility needs to know OPTION’s
    standard value.  So be sure to use an expression which is harmless
    to evaluate at any time.

Previous Next

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