Taylan Ulrich Bayırlı/Kammer <taylanbayirli@gmail.com> schrieb am Sa., 18.
Apr. 2015 um 20:04 Uhr:

> Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
>
> > I think all those discussions are missing the point.
> > If we want to improve the system to the point of considering adding new
> > init files, then we should try and fix other problems at the same time.
> >
> > So here's one of the larger problems:
> >
> > How can we make the system work such that the user can:
> > - Use customize to set package-user-dir, package-pinned-packages, etc...
> > - Use customize to configure a variable which has a :require which loads
> >   a file that's only available after calling package-initialize.
> > The first requires package-initialize to be called late, the second
> > requires package-initialize to be called early.
> >
> > Maybe a solution is to simply make customize-set-variables lazier, so
> > that variables with a :require see their setting delayed to after
> > package-initialize was called.  Or else, have package-initialize be
> > called by customize-set-variables.  Or...
>
> I'm not sure if this isn't an orthogonal problem, but indeed as someone
> who doesn't use Customize I didn't think about it at all, and know
> little about it so excuses in advance for ignorance.
>
> How about Customize being "smart" and separating package-related
> configurations from other ones?  I don't know how hard it would be to
> implement, but it feels like the right design; obviously package related
> customization should be applied before package-initialize, but all other
> customization should be applied after package-initialize, since it's a
> configuration system, meaning it should be one layer above the package
> system, going purely by intuition.
>
> So startup would look like:
>
>   1. pre-package-init.el
>   2. Package related customization.
>   3. package-initialize
>   4. init.el
>   5. All other customization.
>
> Would that work?
>

I think that would be a good solution, although I'd modify it a bit:

1. Contents of init.el before applying customizations.
2. Applying customizations, either inline in init.el or by loading
custom.el from init.el
  2.a. Package related customization
  2.b. package-initialize
  2.c. All other customization
3. Rest of init.el

That would be closer to the current behavior and eliminate the need for
pre-package-init.el.