Re: Summary and next steps for (package-initialize)

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

>> Change package-initialize so it keeps track of what it activated and
>> if called a second time, perform a diff between what was activated
>> before and what should be activated now and based on this activate
>> the new pkgs and deactivate the excess ones?
> This will introduce performance regressions.

Could be.  But I think this should only come up in very unusual
situations (e.g. when you have lots of packages in ~/.emacs.d/elpa even
though you either don't use this directory (and hence set
package-user-dir to something else) or you only activate very few of
them (by setting package-load-list)).

> Besides, having one part of the init process undo a bunch of stuff
> that a previous part did seems like a sketchy design to me.

Can't disagree that "do+undo" is a poor way to do nothing.

> Also, it's impossible for this to work correctly in general since
> autoloads can run arbitrary Lisp code.

The ability to undo is useful in general.  And while it's true that
Emacs can't magically know how to deactivate a package, in general, the
package can provide extra code that explains how to deactivate itself
(e.g. via <pkg>-unload-function).

>> Process ~/.emacs specially so it can start with a special construct
>> (with-early-config ...)
> That seems like a hacky way to try to combine two files into one file.
> Wouldn't it be better to just use two files?

I like to keep my config in a single file, and if you want to use
a separate file you can do (with-early-config (load "my-other-file")),
so while it may be hackish, it's more flexible.

BTW, here's another idea:
- use a separate "early-config" file.  Now, you probably wonder why
  I say it's "another" idea, so here's the reason: this file would be
  loaded before the initial GUI frame is created (so it would solve
  another similar problem at the same time, which is "how do I turn OFF
  those GUI elements in my .emacs such that they never show up, not even
  temporarily while we process the .emacs").
With the expected variant:
- rather than a separate file, accept a special (with-early-config ...)
  form at the beginning of the ~/.emacs.  Oh wait I already suggested
  it, but now this should also be used for "config before the initial frame".


        Stefan