[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#23926: defcustom with STANDARD=<non-pure-expression> gives confusing
From: |
Drew Adams |
Subject: |
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.
bug#23926: defcustom with STANDARD=<non-pure-expression> gives confusing results, Drew Adams, 2016/07/09
- bug#23926: defcustom with STANDARD=<non-pure-expression> gives confusing results, Eli Zaretskii, 2016/07/09
- bug#23926: defcustom with STANDARD=<non-pure-expression> gives confusing results, Drew Adams, 2016/07/09
- bug#23926: defcustom with STANDARD=<non-pure-expression> gives confusing results, Eli Zaretskii, 2016/07/09
- bug#23926: defcustom with STANDARD=<non-pure-expression> gives confusing results, npostavs, 2016/07/09
- bug#23926: defcustom with STANDARD=<non-pure-expression> gives confusing results, Eli Zaretskii, 2016/07/10
- bug#23926: defcustom with STANDARD=<non-pure-expression> gives confusing results,
Drew Adams <=
- bug#23926: defcustom with STANDARD=<non-pure-expression> gives confusing results, Eli Zaretskii, 2016/07/11
bug#23926: defcustom with STANDARD=<non-pure-expression> gives confusing results, Drew Adams, 2016/07/10
bug#23926: defcustom with STANDARD=<non-pure-expression> gives confusing results, Eli Zaretskii, 2016/07/11
bug#23926: defcustom with STANDARD=<non-pure-expression> gives confusing results, Drew Adams, 2016/07/11