bug#23926: defcustom with STANDARD=<non-pure-expression> gives confusing results

[npostavs@users.sourceforge.net]

Eli Zaretskii <eliz@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.