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

[Stefan Monnier]

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

Ah, OK, I'll do that.

>> 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.

Indeed.  Other than eliminate the `blink-cursor-mode` special case,
I can't see how to make it less kludgey.

> 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.

In theory I would agree, but:
- We don't have any such system to record dependencies, so we'd have to
  design and implement it.  A minimal version would simply duplicate
  `customize-initialize-delayed` into two different options depending on
  the stage at which we should initialize it, but that'd still be pretty
  ad-hoc.
- The only need for this complexity is `blink-cursor-mode` and it's only
  needed because we currently handle `blink-cursor-mode` incorrectly.
  So, I'd rather fix the bug and avoid the complexity.

>> 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.

Agreed, which is why the patch I propose keeps this for later.


        Stefan