RE: [External] : Re: Default custom file was: Re: Propose to add setup-wizard.el to ELPA

[Drew Adams <drew.adams@oracle.com>]

> > And what if there's a `custom-set-variables',
> > `customize-set-variable', `customize-set-value',
> > `custom-save-variables', customize-save-variable,
> > `customize-save-all', `custom-save-all',
> > `custom-save-faces', `customize-save-customized',
> > or `customize-saved' in the init file?
> >
> > What if such is not in the init file but in
> > some file that's loaded by the init file?
> >
> > What if such files get loaded conditionally?
> > Are you going to analyze the code and then
> > search through all the possible source code
> > for occurrences?  What if some such code is
> > generated?
> 
> I think this is one of the more important and easily overlooked issue
> raised in this thread. I've noticed in recent times a growing use of
> the various customise functions in a programatic manner within user
> initialisation code. Such code is often spread across multiple files
> which are loaded by the user's init file at startup.
> 
> For this issue, I do have to put myself in the very conservative camp.
> I'm not convinced we have a real issue here and may be either
> creating problems that are more theoretical than actual or guilty of
> premature optimisations.
> 
> For new users, I don't think there are any real issues with the existing
> situation. Most of the issues raised seem to be more issues that arise
> once the user has become more experienced and wants to delve deeper into
> their Emacs configuration. By that point, they will typically have the
> skills to use the existing facilities to break off the custom data into
> its own file and load it at whatever point is appropriate for their
> style of configuration.
> 
> I fear that if we try to make the Emacs startup process 'smarter', we
> are likely to actually make it more frustrating for those who like to
> have fine grained control and unnoticeable by those who don't care. In
> the end, all we get is more complexity wiht little improved
> functionality.

Thanks for your input, Tim.

I have a suspicion that what you're wary of, or
objecting to, is perhaps really the automatic
loading of `custom-file' if it isn't already
loaded.  That's the only "complexity" I can
imagine you think you see.  (I don't see that
just giving `custom-file' a default value adds
complexity.)

If not - if you have a problem also with the
aim of getting more users to use `custom-file',
so as to separate Custom automatic editing of
init files (when it saves) - then what is your
critique of that aim?

(If you agree with that aim, but not with any
of the proposals to move toward it, please
make that clear too.)

To be clear, the aim is not at all "to make
the Emacs startup process 'smarter'", and not
at all to provide some kind of "optimization"
(premature or otherwise).  And I don't think
anything proposed so far does that.

The problem to try to solve - particularly
for new users or users unsure of Emacs Lisp
- is to prevent users (accidentally or with
good intentions) from messing with generated
code, and (less likely) to prevent Customize
from messing with user code.  That's all.

Is that a purely "theoretical" problem?

As I asked earlier:

 The default behavior of Emacs now is to have
 a single file that mixes user coding and
 Custom coding.  Why is that a great idea?
                 ^^^^^^^^^^^^^^^^^^^^^^^^

No one has answered that.  Forget, for a
second (and no, I'm not saying this isn't
important), that there is habit & legacy.

Just imagine that you are designing from
scratch.  Would you really want Customize
(or any other code generation) to write
to a file that users code also?

We don't do that for any other generated
Elisp code.  We write all such code to
dedicated, separate files - not files
that users code in.  (We don't _prevent_
users from editing such files, of course.)

Why do we do that?  Premature optimization?
Paranoid theoretical problem-worrying?

___

In order of decreasing priority (to me):

1. Let's agree on the problem, potential at
   least.

2. Given the problem, let's agree that, in
   some way, we want to prevent mixing user
   coding with automatic coding.

3. Given that aim, let's agree that Customize
   should - by default - save to a different
   file from a user init file.

4. Given that goal, how do we get there?
___

On the road from 1 to 4, how far do you get?

Personally, I get as far as #4.  I proposed
some concrete changes as solution, but #4 is
an open question.

Possible solutions include:

a. At a minimum (I think) explicitly encourage
   users - particularly new users - to define
   `custom-file', and load it to get their
   saved settings.

b. What I proposed, which I won't repeat but I
   can summarize as `custom-file'-default-value.

Please note that even poor (a) has never been
done: we don't encourage use of `custom-file'.

I don't think doing nothing is good (see 1-3).
And I don't think that (a) alone (recommending
use of `custom-file') is sufficient.