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

[Tim Cross]

On Wed, Jul 13, 2011 at 10:31 AM, Stephen J. Turnbull
<address@hidden> wrote:
> 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 *think* I agree, though am not clear what 'saving' means compared to
'setting' within the context of the -Q switch - if it is just a
'no-op' type of operation, it could cause confusion for the user and
if it means something else, I'm not sure what that is.


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

OK, but that does not affect my point regarding the importance of -Q
representing a standard, well defined and consistent configuration.

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

This is getting weird. It seems we both agree that -Q and any changes
to that environment are about more than bug reporting. I think its
about more than reporting. For example, I find it extremely useful in
a diagnostic role and have even found it useful in teaching or
explaining concepts as it ensures everyone is in the same basic
environment.

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

I think we must have very different views on how -Q is used. I do not
see -Q being a switch you would normally use in day-to-day operation.
It is something you do when trying to diagnose a problem, formulate a
recipe for a bug or possibly do some testing/benchmarking/profiling
etc. On some levels, it is reasonable to assume some functionality
which depends on local customization will not work, but that could be
OK given the current context.

>  > 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 ...)
>    (condition-case
>        (customize-save-variable VAR ...)
>      (whatever-error-c-s-v-throws
>       (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.
>
>

Hmm. That wasn't my impression - at least not initially. What I
understood was that he wanted to modify how the save operation worked
under the -Q switch so that it only set the variable and did not warn
the user the value was not saved.  I thought the objective was to make
code that needed to set custom variables at load time able to handle
the -Q situation without the need to jump through extra hoops to avoid
it throwing an error. Others mentioned that having code 'silently'
fail to do what would be expected i.e. save, was perhaps not a great
idea and I tend to agree. However, my concern was whether having code
actually change variables from their default state under the -Q switch
was a good idea at all as it does change the fundamental meaning of
-Q. It means that -Q would no longer mean emacs in a fully default
state to emacs in a default state with some things set to local
values. It is the 'some things set to local values" which I think
could be problematic and my suggestion was that if we do go down that
road, we need a convenient way to know what those some things are and
possibly a reliable way to communicate that information. The overall
point was to question whether this was even a good road to go down at
all or 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 (maybe a warning they are not saved rather
than an error) or perhaps it already does the right thing and what the
code is trying to do is incorrect and needs refactoring.

Tim