On Apr 20, 2015 4:31 PM, "Taylan Ulrich Bayırlı/Kammer" < taylanbayirli@gmail.com> wrote: > > Stefan Monnier writes: > > >> A user is likely to expect everything defined by a package to be > >> available during the execution of their init.el; the failure to meet > >> this expectation is why we get so many confused users asking for help, > >> receiving the answer "just put (package-initialize) at the top of your > >> .emacs". > > > > But the current code in Emacs's "master" solves this problem by adding > > "(package-initialize)" in the user's ~/.emacs. > > I had not realized this is already implemented. > > I generally feel uncomfortable about a tool automatically editing a file > that I assume to have control over, but maybe that's fine. You're not the only one. Other people have voiced indignation. > A concrete problem I can think of is when one has some settings for > package.el in their init file, then Emacs ends up putting > (package-initialize) at the top, when it should be after the package > related settings. Is this not a problem? Slightly, yes. A person who does that sort of thing knows enough to understand they only need to comment out the added call to package-initialize. It would be preferable to not impose this on them though (which is why the whole discussion has been revived). > Other than that, it simply feels wrong to "solve" the problem with a > trick like this as if initializing packages after init.el is the normal > case, when the normal case is that init.el assumes presence of installed > packages. That is, behavior is broken by default, but gets auto-fixed > with a trick like this. WTF? It might be simple to implement, but > conceptually it's rather confusing. > > One might argue it doesn't get conceptually any simpler because there's > simply one init.el and it's agnostic towards package.el, but that's both > wrong (packages are automatically initialized after loading init.el if > it hasn't been done there) and a sign of the package system being > crudely bolted on top of existing machinery. That's stinky engineering. I'm not against a better solution. > I hope I'm not coming off as religious. > > >> If nobody sees any disadvantages, and nobody beats me to it, I might > >> start working on implementing the solution that separates pre-package > >> configuration from normal configuration, including Customize. > > > > I don't really know what solution you're referring to. But so far > > I haven't seen any solution proposed that's really better than > > what we already have. > > Splitting pre-package-initialization configuration from normal > configuration. (Here "configuration" refers to the user's init file as > well as Customize.) Making Emacs init look like: > > 1. pre-package-init.el, & Customize settings in it (or loading > `package-custom-file') > > 2. package-initialize > > 3. init.el, & Customize settings in it (or loading `custom-file') > > This entails extending Customize functionality to offer something like a > :pre-package-init flag which tells the system to write customization for > the relevant defcustom into `package-custom-file' (falling back to > pre-package-init.el) instead of `custom-file' (falling back to init.el). I'm in favor of this. I would suggest you send a new email as a separate thread summarising what will be done, before you go through all the work (though that's up to you). Something similar to what you've just written here, with just a little bit more detail (like saying where the changes will be made) and written with a clear statement of the advantages (reconciling package.el, user code, and custom). > By the way, I just noticed our support for default.el and site-start.el. > I guess said separation of pre- and post-package-init configuration > would be applied to those as well if we were being idealistic, though I > think it should be fine to leave that be and only load default.el and > site-start.el after package initialization. Or can anyone think of > valid use-cases for a site admin to hook in some Elisp before users' > package initialization? I don't think separation needs to be applied to them. If they're currently run before package-initialize, just leave it like that. I don't know why a maintainer would want to run code after package-initialize, but if they want to do that they can use an after init hook.