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.