Taylan Ulrich Bayırlı/Kammer <address@hidden
> schrieb am Sa., 18. Apr. 2015 um 20:04 Uhr:
Stefan Monnier <address@hidden> 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:
2. Package related customization.
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.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.