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

[Tim Cross]

Drew Adams <drew.adams@oracle.com> writes:

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