> To be clear: I do not use the package system Yeah, neither do I. So we're on the same page here. > This is partly because I don't use packages, in general. Remind me to ask why, sometime. > And it is mostly because I use multiple versions of Emacs and > multiple configurations, for testing, and I don't want to be > bothered with telling package.el what to do and not do each time I > use Emacs. I know for a fact that there are alternative package managers which are designed for this sort of use case, unlike package.el. > (I would in fact like that to be even easier than now. "Installing" > packages and enabling them seems too monolithic, to me. It seems to > assume that a given user has only one set of preferences, which s?he > uses all the time.) I doubt this will change soon, as it's a fundamental part of how package.el works. But that's why we have alternative package managers. > But in your proposal the first init file is apparently loaded after > `package-initialize' is done. The order is: 1. Load package.el init-file 2. Run package-initialize, unless package-enable-at-startup was un-set in (1) 3. Load regular init-file 4. Nothing else is done afterwards, unlike currently > So it sounds like users will have `package-initialize' inflicted on > them unconditionally. Wrong. You just (setq package-enable-at-startup nil) in the secondary init-file, and are never bothered by package.el again. This is much better than the current situation, where you still have to (setq package-enable-at-startup nil), but furthermore you have to put an advice on an internal package.el function in order to avoid (package-initialize) from being inserted under some circumstances.