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

[Eli Zaretskii <eliz@gnu.org>]

> From: Radon Rosborough <radon.neon@gmail.com>
> Date: Sun, 20 Aug 2017 10:22:20 -0700
> Cc: emacs-devel@gnu.org
> 
> > Whether the new situation will be better than the current one is
> > arguable,
> 
> I've already explained in my email starting this thread why I think
> the new situation will be better than the current one. If you
> disagree, please tell me why.
> 
> > I don't think it will be significantly better.
> 
> Can you provide justification for this? Such justification would take
> the form of explaining why the advantages I listed are not valid, or
> there are disadvantages that I missed.

Both solutions are problematic and cause user annoyance.  I don't know
how else to explain that.

> > I myself cannot say I like the idea of Emacs creating an init file
> > in the user's home directory.
> 
> Do you like the idea of Emacs modifying the user's init-file
> automatically, even if it already exists? If not, then do you agree
> that my proposal at least reduces the problem?

I don't like either of these, but again, I see no significant
improvement, if at all.

> > I think we should instead explore the possibility that
> > package-initialize will be called only in startup.el. That solution
> > came up during the discussions, but AFAICT was dismissed almost
> > without any serious consideration. The issues raised against it
> > could probably be solved by splitting the package initialization in
> > two, one part before, the other after the user's init file is read.
> 
> Can you please elaborate on exactly how this would work, so that we
> can make an informed comparison of the advantages and disadvantages of
> the proposals?

Basically, leave the call to package-initialize in startup.el where it
is, and add another call at a proper place in startup.el to do
whatever needs to be done before the user init file is processed.
That other call could be to a new function, or even to the same
package-initialize, if it's feasible to do both parts in the same
function (after all, whether the user init file was or wasn't
processed is just a simple test away).

I realize that this is just a repetition of what I said above, but I
don't really understand what needs to be explained here.  If this is
still unclear, perhaps you should ask more specific questions.