> "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.