[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: |
Thu, 24 Aug 2017 19:47:05 +0300 |
> From: Stefan Monnier <address@hidden>
> Cc: address@hidden
> Date: Tue, 22 Aug 2017 23:15:28 -0400
>
> Re-reading what you wrote, I realize that I wrongly interpreted "only in
> startup.el" to mean "after loading the .emacs", whereas My suggestion to
> "call package-initialize before reading ~/.emacs" would actually also
> imply that package-initialize is only called in startup.el.
>
> So we're probably in agreement.
Yes, I think so.
> Calling it in startup.el means either calling it before or after loading
> ~/.emacs, AFAICT.
>
> Calling it after ~/.emacs (like we currently do) is too late since it
> means that ~/.emacs can't use installed packages, and that several
> configurations can't be done in the usual way.
>
> Calling it before ~/.emacs means that package-initialize is done before
> the user got a chance to configure package.el. So we need'd to provide
> some way to reproduce the behavior you can currently get by setting
> various package.el vars before calling package-initialize. E.g. we
> could let a second call to package-initialize de-activate previously
> activated packages and activate previously not activated packages.
Would a ~/.emacs.d/.package-initialize.el file, to be read by
package-initialize before it does anything else, be a better
alternative for configurations that must be done before
package-initialize is called?
Or maybe you have some other alternative ideas for how to make this
happen?
> Packages bundled with Emacs are activated (long) before loading
> ~/.emacs, so calling package-initialize before ~/.emacs seems like the
> most natural behavior in that it makes ELPA packages behave similarly to
> bundled packages.
>
> But then we need some way to deal with users setting
> package-directory-list or package-pinned-packages or package-user-dir
> after package-initialize was called.
Right, which is why I suggested to have a separate file for that.
Thanks.
- RE: Summary and next steps for (package-initialize), (continued)
- Re: Summary and next steps for (package-initialize), Radon Rosborough, 2017/08/24
- Re: Summary and next steps for (package-initialize), Eli Zaretskii, 2017/08/24
- RE: Summary and next steps for (package-initialize), Drew Adams, 2017/08/24
- Re: Summary and next steps for (package-initialize), Eli Zaretskii, 2017/08/24
- Re: Summary and next steps for (package-initialize), Radon Rosborough, 2017/08/24
- Re: Summary and next steps for (package-initialize), Radon Rosborough, 2017/08/24
- Re: Summary and next steps for (package-initialize), Stefan Monnier, 2017/08/22
- Re: Summary and next steps for (package-initialize),
Eli Zaretskii <=
- Re: Summary and next steps for (package-initialize), Stefan Monnier, 2017/08/24
- Re: Summary and next steps for (package-initialize), Eli Zaretskii, 2017/08/24
- Re: Summary and next steps for (package-initialize), Stefan Monnier, 2017/08/24
- Re: Summary and next steps for (package-initialize), Radon Rosborough, 2017/08/25
- Re: Summary and next steps for (package-initialize), Stefan Monnier, 2017/08/25
- Re: Summary and next steps for (package-initialize), Radon Rosborough, 2017/08/25
- Re: Summary and next steps for (package-initialize), Stefan Monnier, 2017/08/25
- Re: Summary and next steps for (package-initialize), Eli Zaretskii, 2017/08/25
- Re: Summary and next steps for (package-initialize), Stefan Monnier, 2017/08/25
- Re: Summary and next steps for (package-initialize), Radon Rosborough, 2017/08/24