[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Calling (package-initialize) sooner during initialization

From: Philipp Stephani
Subject: Re: Calling (package-initialize) sooner during initialization
Date: Sun, 19 Apr 2015 06:44:19 +0000

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:

  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. 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]