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

[Tim Cross]

On Tue, Jul 12, 2011 at 5:28 AM, Lars Magne Ingebrigtsen <address@hidden> wrote:
> Chong Yidong <address@hidden> writes:
>
>> But, on reflection, maybe
>>
>>   (ignore-errors (customize-save-variable ...))
>>
>> would work just as well.
>
> Well, ignoring errors like that is generally not a good idea.  If saving
> the .emacs file errors out, you want to know, for instance.
>
> And it doesn't set the variables in question if you do that.
>
> I think just making `customize-save-variable' set and warn will make the
> "emacs -Q" special case work nicely for all use cases.
>

I think your on the right track, but a couple of things worth thinking about.

An important role of -Q is to provide a well defined, understood
environment which is largely common to all users. It is a key first
step in reproducing bugs. While the current situation where
customizing settings may fail or throw an error and look a bit ugly
etc, it at least does have the advantage of providing a consistent
environment across users. However, as soon as we allow customized
variables to be set, either permanently or temporarily, we run the
risk of losing this valuable environment consistency.

At the same time, this can also be a source of frustration. For
example, if you run emacs -Q to test a recipe for a bug and find it
works, you cannot just run report-emacs-bug to submit the bug if your
mail settings depend on anything but the default values. You need to
copy the backtrace and other important information to a temporary
file, exit emacs and start again without the -Q switch and then submit
the bug. Furthermore, the environment setting you include in the bug
report are now likely to be more complex and not a true reflection of
the actual environment that existed when you ran your recipe under
emacs -Q.

I guess we need the best of both worlds.

One possibility might be to modify the code that manages/sets custom
variables check for the -Q switch and take some additional or
different steps if the -Q switch is also detected. Perhaps something
like using setq and adding the variable and value to a special -Q init
list that cold be included in bug reports etc so that anyone wanting
to reproduce the problem or run the recipe could also run a special
bit of -Q init code to ensure at least consistency with the
environment provided by the reporter/tester etc.

The above is not well thought out - just some thoughts that might
trigger better ideas. The main point is that while it might be nice to
have some better way to deal with code that wants to set custom
variables when runnning under -Q, we also need to try and not lose the
important value provided by -Q of a consistent, well understood
environment with known and tested values for core variables.

Tim