GNU bug report logs - #45857
28.0.50; Not possible to set package-user-dir in early-init.el

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: ola.x.nilsson <at> axis.com, 45857 <at> debbugs.gnu.org, 30994 <at> debbugs.gnu.org
Subject: bug#45857: 28.0.50; Not possible to set package-user-dir in early-init.el
Date: Fri, 15 Jan 2021 09:52:12 +0200

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: ola.x.nilsson <at> axis.com,  45857 <at> debbugs.gnu.org,  30994 <at> debbugs.gnu.org
> Date: Thu, 14 Jan 2021 16:02:30 -0500
> 
> > 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.

But that's still the same kludge: we will rely on the fact that there
are currently no (i.e. zero, a.k.a. "a small number") of such
variables.

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

It isn't ad-hoc, because the stages in the startup process and their
effects are clearly defined and didn't change much for a long time.

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

That'd probably work for another couple of years, and then break
again.  The early-init file introduction is letting a genie out of the
bottle: we don't yet know what it will eventually require, but we
already see some serious problems it causes that we need to adapt to.
I say we should get ready for the future now.  Introducing the
infrastructure I mentioned is not a big deal.

I don't want to argue further about this, so if you are still
unconvinced, so be it.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.