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

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

Tim Cross writes:

 > I *think* I agree, though am not clear what 'saving' means compared to
 > 'setting' within the context of the -Q switch

I think it should mean an error, while the maintainers seem to be (and
Lars clearly is) happy with a warning.  Nobody *wants* silence.

 > OK, but that does not affect my point regarding the importance of -Q
 > representing a standard, well defined and consistent configuration.

Right.  I think there is consensus on that.  My point is simply that
in many cases, -Q will not be a useful environment.  Lars proposes to
make it somewhat more useful, at the cost of complexifying the
behavior of custom-save-variable, and making pollution of the -Q
environment a bit less painful.

 > Hmm. That wasn't my impression - at least not initially. What I
 > understood was that he wanted to modify how the save operation worked
 > under the -Q switch so that it only set the variable and did not warn
 > the user the value was not saved.

Indeed, that was my impression too, as well as Drew Adams'.  But Lars
clarified that he just didn't bother to mention adding a warning, I
guess because he wanted to focus on the major change from signaling an
"unwritable" error to handling it within `custom-save-variable'.

 > However, my concern was whether having code actually change
 > variables from their default state under the -Q switch was a good
 > idea at all as it does change the fundamental meaning of -Q.

I think there is a consensus that this should be avoided when possible
and done very carefully when necessary.

 > whether we are better off leaving -Q to mean EVERYTHING at its
 > default state and doing something else, like having the custom
 > functions do something other than raise an error when code tries to
 > save custom values under -Q

Of course that's what it means.  So the problem is what do you do when
what you need to do *requires* changing state?  I think it's plausible
that almost anything to do with mail will *require* changes to the -Q
state before you get useful behavior.

Note that saving custom values does not change the -Q environment.
It's just that you're unlikely to bother saving in the virgin -Q
environment (you can always reproduce that with -Q!), so an attempt to
save pretty much implies you've already changed state in a significant
way.

 > (maybe a warning they are not saved rather than an error) or
 > perhaps it already does the right thing and what the code is trying
 > to do is incorrect and needs refactoring.

My position is that the code needs refactoring, because I don't like
the idea of facilitating exceptions here, and I think that changing
`custom-save-variable' will make doing customizations in the -Q
environment more attractive.  But that doesn't seem to be the position
of the maintainers.