bug#30994: bug#45857: 28.0.50; Not possible to set package-user-dir in early-init.el

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: ola.x.nilsson@axis.com,  45857@debbugs.gnu.org,  30994@debbugs.gnu.org
> Date: Thu, 14 Jan 2021 14:32:13 -0500
> 
> > Is there any place where all these complications are described, so
> > that people (and we ourselves) could have a complete, comprehensive
> > overview of this stuff and the various problems it needs to solve?  If
> > not, how about taking this opportunity to describe that?  Because
> > otherwise these incidents will keep happening.
> 
> Here's the story:

Thanks, I actually meant to have that in the sources in some prominent
place.

> Currently we solve this by calling `custom-reevaluate-setting` twice for
> every one of those variables.  But it means that we silently override
> any change made to those variables from `early-init.el`.
> 
> As noted, the only var whose default value needs to be (re)computed
> after loading `early-init.el` is `blink-cursor-mode`.  In theory there
> could be more, but I think we should aim to reduce rather than increase
> those cases.

I think relying on a small number of such variables is not
future-proof enough.  This case is a living proof: we decided
something 2 years ago, but changes we did since then require us now to
change that decision, which means we risk bumping into issues which we
wanted to avoid back then.  That's a general problem with kludgey
solutions.

I think we need some new infrastructure that would support the two
init files that are loaded in different stages of startup.

Basically, some variables can only be usefully initialized after some
part(s) of startup have happened already.  One way of dealing with
this is to have the variables record this information (e.g., in a
plist of their symbol) that would allow us evaluate each variable only
once, at the earliest opportunity where the prerequisites are
fulfilled.

> E.g. the current way `blink-cursor-mode` is defined means that if I
> start `emacs -Q -nw` and later create a GUI frame, that frame won't
> have a blinking cursor.  I think this is a bug (tho I can see that
> some people may consider it a feature if they (like me) dislike
> blinking cursors ;-0)

I think that's a separate issue.