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.