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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: npostavs <at> users.sourceforge.net
Cc: 23926 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: bug#23926: defcustom with STANDARD=<non-pure-expression> gives
 confusing results
Date: Sun, 10 Jul 2016 17:19:15 +0300

> From: npostavs <at> users.sourceforge.net
> Cc: Drew Adams <drew.adams <at> oracle.com>,  23926 <at> debbugs.gnu.org
> Date: Sat, 09 Jul 2016 16:48:23 -0400
> 
> > Of course, I do.  Maybe you don't realize how many times Emacs
> > evaluates the value of a defcustom, but I do.
> 
> What about making Emacs evaluate it less? e.g. replace occurences of
> (eval (car (get var 'standard-value))) with
> 
> (or (get var 'original-value)
>     (let ((val (eval (car (get var 'standard-value)))))
>       (put var 'original-value val)
>       val))

What will that do to the likes of custom-reevaluate-setting?

FWIW, I wouldn't try making any such changes in this area.  The number
of evaluations and the precise triggers for evaluating a defcustom is
a fragile setup, and I'd hate breaking it.  Certainly not for a
marginal use case such as the one in this report.  In effect, 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?

Previous Next

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