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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 23926 <at> debbugs.gnu.org, npostavs <at> users.sourceforge.net
Subject: Re: bug#23926: defcustom with STANDARD=<non-pure-expression> gives
 confusing results
Date: Mon, 11 Jul 2016 21:40:16 +0300

> Date: Sun, 10 Jul 2016 10:18:27 -0700 (PDT)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: 23926 <at> 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.

Previous Next

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