From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#30994: 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 Message-ID: <835z3ybpsj.fsf@gnu.org> References: <83o8hrbbv6.fsf@gnu.org> <83h7njb6a5.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2561"; mail-complaints-to="usenet@ciao.gmane.io" Cc: ola.x.nilsson@axis.com, 45857@debbugs.gnu.org, 30994@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jan 15 08:53:11 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1l0Juw-0000X8-TA for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 15 Jan 2021 08:53:10 +0100 Original-Received: from localhost ([::1]:40740 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l0Juv-0001bL-Ek for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 15 Jan 2021 02:53:09 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56742) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l0Juo-0001aw-CO for bug-gnu-emacs@gnu.org; Fri, 15 Jan 2021 02:53:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:56514) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1l0Juo-000519-4K for bug-gnu-emacs@gnu.org; Fri, 15 Jan 2021 02:53:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1l0Juo-0005hT-2h for bug-gnu-emacs@gnu.org; Fri, 15 Jan 2021 02:53:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 15 Jan 2021 07:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 30994 X-GNU-PR-Package: emacs Original-Received: via spool by 30994-submit@debbugs.gnu.org id=B30994.161069714421855 (code B ref 30994); Fri, 15 Jan 2021 07:53:02 +0000 Original-Received: (at 30994) by debbugs.gnu.org; 15 Jan 2021 07:52:24 +0000 Original-Received: from localhost ([127.0.0.1]:39825 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l0JuC-0005gQ-A4 for submit@debbugs.gnu.org; Fri, 15 Jan 2021 02:52:24 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:35306) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1l0JuA-0005gA-Cv; Fri, 15 Jan 2021 02:52:22 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:40713) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l0Ju3-0004iE-2l; Fri, 15 Jan 2021 02:52:16 -0500 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4080 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1l0Ju2-0001KG-Is; Fri, 15 Jan 2021 02:52:14 -0500 In-Reply-To: (message from Stefan Monnier on Thu, 14 Jan 2021 16:02:30 -0500) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:197974 Archived-At: > From: Stefan Monnier > Cc: ola.x.nilsson@axis.com, 45857@debbugs.gnu.org, 30994@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.