[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Summary and next steps for (package-initialize)
From: |
Eli Zaretskii |
Subject: |
Re: Summary and next steps for (package-initialize) |
Date: |
Sun, 20 Aug 2017 20:36:38 +0300 |
> From: Radon Rosborough <address@hidden>
> Date: Sun, 20 Aug 2017 10:22:20 -0700
> Cc: address@hidden
>
> > 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.
- Re: Summary and next steps for (package-initialize), (continued)
- Re: Summary and next steps for (package-initialize), Radon Rosborough, 2017/08/20
- Re: Summary and next steps for (package-initialize),
Eli Zaretskii <=
- Re: Summary and next steps for (package-initialize), Radon Rosborough, 2017/08/20
- Re: Summary and next steps for (package-initialize), Eli Zaretskii, 2017/08/21
- Re: Summary and next steps for (package-initialize), Radon Rosborough, 2017/08/21
- Re: Summary and next steps for (package-initialize), Eli Zaretskii, 2017/08/21
- Re: Summary and next steps for (package-initialize), Radon Rosborough, 2017/08/21
- Re: Summary and next steps for (package-initialize), Eli Zaretskii, 2017/08/21
- Re: Summary and next steps for (package-initialize), Radon Rosborough, 2017/08/22
- Re: Summary and next steps for (package-initialize), Clément Pit-Claudel, 2017/08/22
- Re: Summary and next steps for (package-initialize), Radon Rosborough, 2017/08/22
- Re: Summary and next steps for (package-initialize), Eli Zaretskii, 2017/08/22