[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bug#30854: 27.0.50; Speeding up package.el startup
From: |
Arthur Miller |
Subject: |
Re: bug#30854: 27.0.50; Speeding up package.el startup |
Date: |
Tue, 22 Dec 2020 21:45:04 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> Set `package-load-list`.
>> Is it up to user to serialize this list to disk for next session or
>> is it somehow done on the user behalf?
>
> It's assumed it's manually set in the user's init file or via Custom, yes.
>
> For example, I locally disable AUCTeX as follows:
>
> (setq package-load-list '((auctex nil) all))
>
>> If user disabled a package, and generated new autoloads, and then
>> there were new packages installed in site repository, how would Emacs
>> know which are disabled and which are just new ones?
>
> If `package-load-list` says it's disabled, then it's disabled, and if
> not, then it's not. I guess I don't understand the question.
>
>> 1. is probably trivial, since package.el already can do that. It
>> just needs to call package-quickstart-refresh from few more places.
>
> Right.
>
>> 2. as well
>
> Indeed.
>
>> 3. will need some extra code, mostly or only in startup.el
>
> It also needs extra code in `package.el` when creating
> `package-quickstart.el` to record the mtimes.
>
> BTW, other cases where the `package-quickstart.el` needs to be recreated
> is when the user changes `package-load-list` or
> `package-directory-list`, so we may also want to remember the values of
> those vars when creating the `package-quickstart.el`. But this part is
> more tricky: it can be perfectly normal for the users to set those vars
> in their init file, i.e. after `package-quickstart.el` is loaded (it's
> actually one of the benefits of using `package-quickstart.el`: you don't
> need to set `package.el`'s vars in your `early-init.el`), so we should
> not check those vars for freshness before loading
> `package-quickstart.el` but rather later.
>
>> 4. will need some extra code in package.el, maybe in startup.el too, not sure
>
> AFAIK there's nothing to be done for 4.
I think I like 4. best so far.
- Re: bug#30854: 27.0.50; Speeding up package.el startup, (continued)
- Re: bug#30854: 27.0.50; Speeding up package.el startup, Arthur Miller, 2020/12/21
- Re: bug#30854: 27.0.50; Speeding up package.el startup, Stefan Monnier, 2020/12/21
- Re: bug#30854: 27.0.50; Speeding up package.el startup, Arthur Miller, 2020/12/21
- Re: bug#30854: 27.0.50; Speeding up package.el startup, Stefan Monnier, 2020/12/21
- Re: bug#30854: 27.0.50; Speeding up package.el startup, Arthur Miller, 2020/12/22
- Re: bug#30854: 27.0.50; Speeding up package.el startup, Stefan Monnier, 2020/12/22
- Re: bug#30854: 27.0.50; Speeding up package.el startup, Arthur Miller, 2020/12/22
- Re: bug#30854: 27.0.50; Speeding up package.el startup, Stefan Monnier, 2020/12/22
- Re: bug#30854: 27.0.50; Speeding up package.el startup, Arthur Miller, 2020/12/22
- Re: bug#30854: 27.0.50; Speeding up package.el startup, Stefan Monnier, 2020/12/22
- Re: bug#30854: 27.0.50; Speeding up package.el startup,
Arthur Miller <=
- RE: bug#30854: 27.0.50; Speeding up package.el startup, arthur miller, 2020/12/19
- RE: bug#30854: 27.0.50; Speeding up package.el startup, arthur miller, 2020/12/19