> "You tried to call X which is not available and Emacs package
> manager was not initialized.
I think this proposal is worse than adding a second init-file. Here is
why:
* It is much more annoying to the user. The second init-file would
mean that everything works in all cases with *no* user interaction.
Making users deal with pop-up dialogs wastes their time.
* The user might well be calling a function that is provided by
another package manager, or indeed a manually loaded Lisp library.
Emacs can't assume that all undefined functions are the fault of not
calling package-initialize; undefined function errors have a scope
that is many orders of magnitude greater than the package system.
Besides, what about when Emacs is run in batch mode? Then we're back
to where we started, since there's no option to prompt for user
input.
* > w writes (package-initialize) to init)
This is bad. We don't want Emacs doing this under any circumstances.
Not because it might be annoying (though it is), but because *Emacs
usually does it wrong*! If you put `package-initialize' in the
init-file, you *must* put it after any package.el configuration, but
before any package configuration. This point is impossible to
determine in general, especially as it might be elsewhere on the
filesystem.
* > K would set variable
> dear-emacs-i-totally-don-t-need-any-begginers-advice-thanks to t.
How? By modifying the init-file? This whole discussion started
because we don't want package.el doing that. (Admittedly, this
wouldn't be as bad as trying to add `package-initialize' -- but
still.)
* > I'm not entirely sure on the technical side of catching requires
> and void-functions
Seems pretty sketchy. You're going to mucking around with one of the
most fundamental parts of the Elisp interpreter (namely, function
calls) just for the sake of the package manager.
Adding a second init-file doesn't require anything this hacky.
> Also similar approach is already used in Emacs, there's some key
> binding that's disabled until you confirm it in a similar way, sorry
> at the moment I don't remember which one.
You're thinking of disabled commands. But that's very different: the
popup only appears when a user explicitly tries to do something
dangerous, rather than during noninteractive execution of arbitrary
Lisp code. And furthermore, the disabled-command mechanism serves to
prevent users from shooting themselves in the foot; whereas, if Emacs
tries and fails to put `package-initialize' in the right place
automatically, it is shooting the user in the foot all by itself.
> but this seems to be the best solution when all other things are
> considered
To me, it seems to be worse than the second init-file proposal in
every way except that it doesn't require the addition of a second
init-file, and that it might have better backwards compatibility. But
I am sure there are things I am missing in my analysis; please let me
know if this is misguided.