|Subject:||Re: Calling (package-initialize) sooner during initialization|
|Date:||Sun, 19 Apr 2015 09:11:02 +0100|
On Apr 19, 2015 7:44 AM, "Philipp Stephani" <address@hidden> wrote:
> 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.
I'm afraid this step is already a problem. If these initial contents contain a (require 'some-package), the user will be given an error during initialization.
That's why Taylan's solution has an extra file. It's annoying, but necessary.
> 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.
It would be so close to the current behaviour that the problem wouldn't be solved. ;-)
The point here is that it needs to just work for the less knowledgeable user. We can't expect them to move their call to (require 'some-package) until after the custom.el snippet is loaded. Not to mention, they might not even have such a snippet.
|[Prev in Thread]||Current Thread||[Next in Thread]|