Re: Change `customize-save-variable' to work under "emacs -Q"?

["Stephen J. Turnbull" <stephen@xemacs.org>]

Tim Cross writes:

 > I have used that technique, but have run into problems with packages
 > that have already loaded where the variable needs to be set before
 > they are loaded.

Granted, but that belongs to the "do what's needed to reproduce the
bug" part of my workflow.  I don't see how it's relevant to the
discussion of *excessive* changes to the -Q environment.

 > The core issue I see is that -Q is useful mainly because it
 > establishes a standard default environment.
[...]
 > Once we allow local customizations to be applied in this
 > environment, this standard base default environment no longer
 > exists. This may be fine, provided there is some mechanism that
 > makes what has been changed explicit and easy to reproduce.

I think that Customize already provides some function for listing
variables that are not at their default values, both Customized and
"rogue" values.  Its output could be added to the bug-reporter's
buffer (maybe it's already there in Emacs, but XEmacs doesn't do that
yet).  Perhaps it should be glossed with a comment that only
defcustoms can be listed this way.

 > Bug reporting was not meant as the central theme - it was just an
 > example of one thing that could be affected when you allow local
 > customizations to be applied in a -Q environment.

OK.

 > What I don't want to see is one party reporting something in a -Q
 > environment that is not seen in another -Q environment (assuming
 > other things, such as platform, version etc being equal)

I'm not sure I understand.  Isn't that just a symptom of a poor
report, ie, omitting necessary preparation for reproducing the
behavior from the recipe?  AIUI Lars' code is *not* going to suffer
from the problem you describe: only *necessary* changes to the -Q
environment will be made, and it's the reporter's responsibility, as
usual, to describe them accurately.  I'll let Lars speak to the
details, though.

 > What I don't want is local customizations that are applied 'behind
 > the scenes' or are only applied to some things and not others.

Sure.