On Apr 19, 2015 7:44 AM, "Philipp Stephani"
wrote:
>
>
>
> Taylan Ulrich Bayırlı/Kammer schrieb am Sa.,
18. Apr. 2015 um 20:04 Uhr:
>>
>> Stefan Monnier 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.