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

[Tim Cross]

On Tue, Jul 12, 2011 at 2:12 PM, Stephen J. Turnbull <address@hidden> wrote:
> 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.
>

I don't think "'excessive' changes" is an accurate reflection of what
has been discussed her. The issue is about a package which needs local
settings which are normally handled by the 'custom' framework.
However, when you are running with -Q (and possibly -q), your .emacs
is not loaded and no cusotmizations are in effect. To complicate
matters, some of the functions in the custom package do not work well
or do not work at all if the user's .emacs is not loaded or cannot be
saved to. I think Lars wants to find a way to make code, such as
smtpmail (I'm gussing) work in a 'clean' way under -Q.

My contribution (FWIW) was to try and emphasize that as soon as you
allow local configuration settings within the -Q environment, you are
fundamentally changing the familiar semantics of that environment. It
is no longer the stock standard, out of the box environment which can
be duplicated by anyone simply through adding the -Q switch. To get
consistency between two environments, it would now be necessary to
perform additional steps.

[..]

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

You could look at it as a symptom of poor bug reporting, but that
isn't sufficient. Bugs are often reported by people with little
experience and it can be difficult to know what to include and what
not to. A consistent -Q environment helps by creating a consistent
setup that can be communicated easily as "start with emacs -Q".  We
even tell people to see if the issue they have continues when you run
under -Q. However, once we lose this standard environment because it
may have local configuration settings, we cannot know for certain.
Someone reports a problem they see under -Q, but which someone else
does not see and now we don't know if its due to local customization
or some other issue.

However, please, move past bug reporting. The -Q is useful in many
other scenarios. Think of it as the ultimate emacs reset button. With
-Q everything goes back to the factor defaults.  Ironically, I only
really mentioned bug reporting as it was an example of how allowing
local customization could make that process easier, but at the same
time, potentially make other things harder - a double edged sword if
you like.

Once you change default settings in any way, this property of the -Q
switch is lost. Yes, in many cases, it may not be an issue and yes, it
may make some things, such as mail, work. However, this is irrelevant
to the fact it fundamentally changes -Q in subtle ways that could have
other side effects. This may well be acceptable, but if this is the
case, it needs to be a decision made after considering such factors.
An alternative solution is to accept that some packages, those that
require local configuration, just don't work under -Q.


I also think it is dangerous to just consider what Lars requires.
While we may modify/add a feature to address the specific problem he
is encountering, we also need to consider whether over time, others
may use that facility incorrectly or in ways that were not thought of
when it was implemented and what the consequences of that may be.

My view is that the objective Lars is after is reasonable and we need
to support his efforts. At the same time, I would like to do this in a
way that does not change the semantics of -Q, or if it must, does so
in a way where it is easy to get the environment consistency that -Q
previously provided. There are numerous ways I think this could be
done. An additional switch may be worth considering (either to force a
'only factory defaults' type setting or allow some 'customization' for
specific packages - my only hesitation is contributing to emacs
becoming a program that has such complex and numerous command line
switches that they themselves become an issue!

Tim