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

[Mauro Aranda]

In case it wasn't clear in my previous message, I'm focusing on the
Customize part of the problem here.  I went through a lot of the
defcustoms we have in source, and found out that there are many, so
many, that can potentially show this inconsistency.  The one that's
comparable to the test case given is archive-tmpdir, but there are
others.  I've classified them in 6 categories, as:

- Standard value changes every time its standard form is evaluated
This is archive-tmpdir.

- Standard value depends on special conditions in an Emacs session
For example, highlight-changes-colors depends on the background-mode
frame parameter.  I've seen it's somewhat common to use different themes
(light and dark) in a session, so using a frame-parameter query as
standard is not optimal.  There are other cases like erc-nicks-bg-color,
vc-annotate-background-mode, etc.

- Standard value depends on some external (usually OS-related) condition
These are mostly defcustoms that try to find a program available.
Examples are remote-shell-program, wallpaper-command, etc.  The standard
values could change, potentially, if some program gets installed while
an Emacs session is active.

- Standard value depends on a built-in option
Take for example ido-case-fold, or ibuffer-case-fold-search.  If those
options get defined and after that the user customizes case-fold-search,
it will exhibit the inconsistency presented in this bug report.  What's
worse, is that the current session may show a different behavior than a
new session, if the user saves the customization for case-fold-search.

- Standard value depends on an option from the same package
gnus-*-directory options are a good example here.

- Standard value depends on another's package option
For example, erc-button-url-regexp that depends on
browse-url-button-regexp.

- Standard value depends on finding an Emacs-related file
This is usually detected with a call to locate-user-emacs-file with two
arguments, trying to keep backward-compatibility with an older filename.
For example, bookmark-default-file, diary-file, timeclock-file, etc.

I left this for last, because while it might potentially show the
problem, it should be rare enough to consider it a non-issue.


That's a summary of what I've found.  I would like to find a way to make
the Customize part of this problem less confusing (or better, no
confusing at all), keeping in mind backward-compatibility, of course.  I
don't have any clear ideas yet.