> The ability to undo is useful in general.
It's true, but most packages don't provide this capability, so if
package.el relies on it, then usage of package.el will produce more
bugs.
> 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).
That tells how to unload the feature <pkg>, not how to undo the
effects of the autoloads for all features in the package. Sure, the
package can provide metadata that tells how to undo its autoloads, but
this will be an additional system separate from <pkg>-unload-function.
Unless we want to tell people they have to write their
<pkg>-unload-function so that it works even if unloading a feature
that hasn't been loaded yet...
> 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").
I think this is a really great idea, and would fit in well
conceptually. It would also resolve the concern that Nikolay raised
earlier about ~/.emacs.d/.package-initialize.el later becoming
extraneous if we refactor the feature loading system.
> rather than a separate file, accept a special (with-early-config
> ...) form at the beginning of the ~/.emacs.
I guess I would be fine with this, even though I think it's a little
hacky.
Best,
Radon
P.S. I notice you keep saying ~/.emacs. Is that out of
habit/convenience? I thought ~/.emacs was deprecated in favor of
~/.emacs.d/init.el.