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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 10 Jul 2016 10:18:27 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 23926@debbugs.gnu.org
> 
> It can sometimes make a lot of sense for a defcustom to use a sexp
> that might not return the same result when reevaluated.

One way to do that while avoiding the issue at hand is to define a
'set' function to do the job, instead of doing it explicitly in the
initialization value.

> The original bug, from which this report is an offshoot, was #4755.
> The example there used this defcustom sexp: `(copy-sequence foo)'.
> 
> And in the context of the using code there is nothing wrong with
> such a sexp: the intention is really to use, as default value, a
> (new) list whose elements are the (exact same) elements as those
> in the list `foo'.

I guess it's crystal-clear now what's wrong with such a sexp.

> The problem is not with being able to make use of such a sexp for
> the default value.  The problem is with how Emacs talks about the
> state of the option value.  It miscommunicates to users.  That's
> what this bug is about: how Emacs talks about what is going on.

Emacs says the truth: the value of the defcustom was changed behind
Customize's back.

And since I've already said all that once before, let's stop going in
circles.  Nothing wrong with agreeing to disagree.