[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Radon Rosborough
Subject: Re: Summary and next steps for (package-initialize)
Date: Thu, 24 Aug 2017 18:04:11 -0700

> > 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?
> To me, it'd be a worst case fallback if we can't find a better
> solution.

That's a reasonable perspective. I personally do think that there is
no better solution.

Also, I really like the naming and the idea that the file is loaded by
`package-initialize', not directly by startup.el.

> Change package-initialize so it keeps track of what it activated and
> if called a second time, perform a diff between what was activated
> before and what should be activated now and based on this activate
> the new pkgs and deactivate the excess ones?

This will introduce performance regressions. Besides, having one part
of the init process undo a bunch of stuff that a previous part did
seems like a sketchy design to me. Also, it's impossible for this to
work correctly in general since autoloads can run arbitrary Lisp code.

> Process ~/.emacs specially so it can start with a special construct
> (with-early-config ...)

That seems like a hacky way to try to combine two files into one file.
Wouldn't it be better to just use two files?

> I've had other ideas, but they generally suck one way or another.

Me too. For example, I now think that my original idea of generating a
template init-file is a less effective solution than

reply via email to

[Prev in Thread] Current Thread [Next in Thread]