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

[Radon Rosborough <radon.neon@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3012 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 3930 bytes --]