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

[Tim Cross <theophilusx@gmail.com>]

On Wed, Jul 13, 2011 at 9:02 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:
>  > 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.
>

Agree, but perhaps disagree on how those changes occur. I would prefer
that the individual has to explicitly (even manually) make those
changes rather than have emacs attempt to anticipate what the user may
need when running under a -Q environment. Of course, the downside with
this approach is that those who are less comfortable/familiar with
emacs will find this difficult.

> 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.
>

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. The
default location I gues swould be the users .emacs file. However,
quite a few users also customize this and have the custom variable
stuff in a different file because they don't want it mixed up with
other stuff in .emacs. Now we have a problem. The -Q switch does not
read the .emacs file and therefore we cannot tell which aproach this
user prefers and therefore, don't know where we should save these
values to. This is why I don't understand what 'save' means in this
context or how it would work. Worse yet would be a situation where the
user becomes confused when they believe they have saved settings while
under -Q, but then next time they run emacs (with or without -Q) their
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?

>  > (maybe a warning they are not saved rather than an error) or
>  > perhaps it al> 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.
>

I'm divided on error v's warning. On one hand, an error is good as it
grabs user attention and makes it clear the values have not been saved
- avoiding later confusion. The downside is that it can make the code
more complex for developers when -Q is invoked. On the other hand, it
could be argued that as this is a known and understood situation, a
warning is sufficient. The advantage is that some code would become
less complex. The downside is that users may easily overlook the error
and then get confused when their settings don't seem to be persisting
over sessions etc.

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. If this
problem is relatively rare and really only comes up when you would
like a package to have some level of functionality under -Q and that
can only be achieved by setting values, then an error would certainly
seem to be the right choice. However, if this is a frequent issue and
an error is resulting in frequently more complex initialization code,
then there could be a case to downgrade it to a warning. On the other
hand, I would be tempted to look at refactoring how defaults and
custom work as this would indicate a deeper design issue IMO.

>  > 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.

Yes - I worry about it becoming easier to pollute the -Q environment
and whether this will reuslt in -Q becoming less useful over time. I
think it is reasonable to expect the -Q environment to be less
'useful' than the standard environment. It is a special purpose
environment and losing some functionality in such an environment is
acceptable - especially if the lost functionality is functionality
that depends on local configuration.

>
> 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.
>

It would seem we are of similar opinions. I too am concerned that
making it easier for code to change custom variables under -Q
environments will result in -Q losing its important quality of
representing a standard default environment. The suggested changes to
custom functions certainly feels wrong in the sense that it seems to
be muddying their definition and making matters more complex than
desirable. I also suspect that the desire to make -Q more functional
may be misplaced.

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

Tim