[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Stephen J. Turnbull
Subject: Re: Change `customize-save-variable' to work under "emacs -Q"?
Date: Wed, 13 Jul 2011 09:31:30 +0900

Tim Cross writes:
 > On Tue, Jul 12, 2011 at 2:12 PM, Stephen J. Turnbull <address@hidden> wrote:

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

The right way is to use different functions to do the `set' part,
which Customize already provides.

As an Olde Farte, I am often nonplussed by software that doesn't offer
to set or save, but simply reflects changes in the dialog in the
settings immediately, and saves them when the dialog is dismissed (or
perhaps before).  It seems to me that a better approach than screwing
with the semantics of "save" and turning it into "save in some
circumstances but not others and you'd better remember which you're
in, until the end of the session which may be a long time from now",
simply do that set (which AFAIK can't fail) and then do a separate
save, which makes it clear WTF the code is doing.

 > > 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?
 > You could look at it as a symptom of poor bug reporting, but that
 > isn't sufficient.

I very carefully removed "bug".  This is not about bug reporting, it's
about communication including bug reporting but not limited to it.  I
use the word "report" to indicate that certain aspects of the
communication need to be precisely stated.

 > Once you change default settings in any way, this property of the -Q
 > switch is lost.

Sure.  I don't see how anything I said depends on *bug* reporting.
What it depends on is making changes to the environment.  In the case
of mail, this may mean choosing a non-default transport (smtpmail
vs. sendmail) and setting user options (full name and mail address)
and so on.

 > An alternative solution is to accept that some packages, those that
 > require local configuration, just don't work under -Q.

Well, sure.  All that means is that people will continue to use -Q as
"the ultimate Emacs reset" (quote of the week!) and proceed to modify
that environment as necessary to do the work they're going to do.  It
will be their responsibility to report those modifications in order
for others to reproduce the behavior ....

 > My view is that the objective Lars is after is reasonable and we need
 > to support his efforts.

We already do.  There's nothing hard or unclear about 

    (customize-set-variable VAR ...)
        (customize-save-variable VAR ...)
       (warn "VAR set but not saved because you haven't loaded custom file")))

Lars just thinks that Emacs should be smart enough to do that itself.
I think, as the Japanese say, this is ten years too early for that
kind of smartness.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]