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

Previous Next

Full log

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

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>, npostavs <at> users.sourceforge.net
Cc: 23926 <at> debbugs.gnu.org
Subject: RE: bug#23926: defcustom with STANDARD=<non-pure-expression> gives
 confusing results
Date: Sun, 10 Jul 2016 10:18:27 -0700 (PDT)

> whoever uses current-time-string as a defcustom's value tells Emacs that
> the value is not important, because the programmer has no idea when in
> the process of building and restarting Emacs will the value be taken.
> Why does it make sense to rock the boat in this sensitive area for such
> use cases?

Obviously, `(current-time)' was an example, to demo show the problem.

It can sometimes make a lot of sense for a defcustom to use a sexp
that might not return the same result when reevaluated.

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'.

And yes, this (intentionally) means that the user option, `toto',
that has this value can share the objects that are its initial
elements.  Nothing wrong with using such an initial value for a
user option.

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.

Previous Next

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