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

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

Tim Cross writes:
 > On Wed, Jul 13, 2011 at 9:02 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:

 > > 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.
 > 
 > Agree, but perhaps disagree on how those changes occur.

I think you and I agree that having M-x sendmail prompt for values is
implicit, but I'm pretty sure Lars would consider that to be an
explicit change.

 > I guess your saying that saving and setting are different operations
 > and saving without setting would not affect the current environment?
 > What I'm not clear about is where you would save the values to.

Well, in XEmacs it's not really a problem because by default
customizations are saved to ~/.xemacs/custom.el, so I haven't really
thought about it.  A bit of reflection suggests that if the default is
.emacs, this is a real hairball.  However, neither of the options
currently being advocated (status quo with an error before setting the
variable vs. catch the error, set the variable, issue warning)
actually does save so the point is moot, I think.

That issue aside, IMO if a failure to save customizations in the -Q
environment is a problem for some code, that code should handle it.
In general, I want to discourage use of Customize in the -Q
environment because Customize does way too much magic behind the
scenes (a Customize setter can do *anything*).  As soon as a recipe
says "Customize variable X to Y," you're in a situation where you must
analyze Customize as well as the main code.

 > changes have not been saved.  To some extent, I would guess this is
 > primarily why you would argue for an error rather than a warning -
 > making it very clear to the user their save action has failed?

No, my primary reason is the above.  If the warning is obstrusive, the
user won't miss it, and it's unlikely that much harm will be done even
if they do.  They just have to redo the customization in a session
without -Q, and only if that is "hard" is there a real loss.

 > I personally think an error is better. However, I also don't fully
 > understand how often package maintainers run into problems
 > initializing their packages when they are run under -Q.

Lars says it's not about the package maintainers, it's about the
users.  It's none of our business why the user is running a mail
command in -Q environment, but we should make that as painless as
possible.

I agree, I just think that it's better to have the burden of handling
errors occasioned by operating in the -Q environment placed on
developers rather than done behind the scenes by Emacs.

 > Yes - I worry about it becoming easier to pollute the -Q environment
 > and whether this will reuslt in -Q becoming less useful over time.

Exactly.

 > I guess we will have to wait and see what evolves.

Sure.  But although Lars may have long since killed this subthread, I
suspect Stefan and/or Yidong lurked long enough to get the point.
That doesn't mean they'll agree with us, of course.

Until next time :-),