From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Radon Rosborough Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Fix `early-init-file' value when file is missing Date: Sun, 10 Feb 2019 15:04:59 -0800 Message-ID: References: <8336p7zxdf.fsf@gnu.org> <83bm3mrazc.fsf@gnu.org> <837eeaosm9.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000cbf6580581923a8c" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="50704"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 11 00:06:47 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gsyBT-000D6w-IA for ged-emacs-devel@m.gmane.org; Mon, 11 Feb 2019 00:06:47 +0100 Original-Received: from localhost ([127.0.0.1]:37810 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gsyBS-0007GK-BT for ged-emacs-devel@m.gmane.org; Sun, 10 Feb 2019 18:06:46 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:39679) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gsyAo-0007GF-C5 for emacs-devel@gnu.org; Sun, 10 Feb 2019 18:06:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gsyAm-0000fc-F7 for emacs-devel@gnu.org; Sun, 10 Feb 2019 18:06:06 -0500 Original-Received: from mail-ua1-x944.google.com ([2607:f8b0:4864:20::944]:45297) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gsyAe-0000Su-IB; Sun, 10 Feb 2019 18:05:56 -0500 Original-Received: by mail-ua1-x944.google.com with SMTP id e16so2825639uam.12; Sun, 10 Feb 2019 15:05:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cd4rVWLxYJDVGqf1Ngl233tGkVKC4HMbWlql5xvPf1c=; b=GYLrBYcEGGVXg992IMJVJdFY1JgoWKOqffYKbNI2hQhXiQKIuMMUzNsn05lrScyRvt 4HwRMF1PtCqm/ALaXJc2KJ7lDjG262k1xaFL5m5Ig1EieyEQASYdwiV+9T25WjBOGwKH FeIg4eobKEm0F7xifL1j+DE51Rma/3zYiWqduq7smr3aG67KPKHCA+UWLxREkJiW4Ehj CiB5xU0LnT3ukGSqKunmKQYD4Sf5Am9VNvPoVCIN1EMaFP98AM+dzxRdNAvpn56gZcEH NG13UfR2djL1hKHvSfT8DzAn5TZmb1Z3O8/NJV22jUxbgQKGrvzRLMbKdcMLEnHnfkuC l+aQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cd4rVWLxYJDVGqf1Ngl233tGkVKC4HMbWlql5xvPf1c=; b=argePBji0TiBJYcbHWCfTnd8raapXedj1DnPXZYHeyP29zT3QFPDnWjQM/Off/XtMo 60tc9eggV5Xd5RdK1/sifhlKoKGyNP8EAFcOrRjeXAnE5XqJjKQ7BAu4TRq4KDLYAe+X pq9QnDSZXKO54GoS2Kf3Zp7a4K61sN0seEN5blQS5TvIa4J9+hlJCLWRDUVNhVbL/ESv 45pZvAdGj4R+kxH1vndDOJuMFKs2rh3w2jmS619Fegfo5G68zlUz5FcAMpYW45iLzFFO aacNRuSgLMZiizEiK95wATh9kTpLOAyUDuXP1Hg+mHtGCX4E8ZGL6mwzGJ6hfkPe2Lmn JgFg== X-Gm-Message-State: AHQUAuZRS9fItlXfoYKjhws7BRbRw0PvhmdAH8qzWGGwkXYnYsFOGFH1 aGC15IgKlrmokya9/9sV32sykcUxHnv2tMwNkNxKMg== X-Google-Smtp-Source: AHgI3IZeFKO8TGUqBLGTPGQWayPNc0ALgolX8Tzy7hsaEmwJrCp+L4Tx1hNj71dLQBstpZYUVZH5xBrQoGRLXk20m5A= X-Received: by 2002:ab0:3407:: with SMTP id z7mr11423388uap.115.1549839935205; Sun, 10 Feb 2019 15:05:35 -0800 (PST) In-Reply-To: <837eeaosm9.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::944 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:233208 Archived-At: --000000000000cbf6580581923a8c Content-Type: text/plain; charset="UTF-8" > you've modified the API of load-user-init-file But we have never released a version of Emacs that includes this function -- and it's an internal function. There are only two callers of this function that exist, and they are both touched by this patch. But, okay, the only reason I changed the arguments was because I thought it was an improvement. Would you accept a patch that fixed this bug without changing the arguments? > All you want is to set a single variable to a specific value if the > file wasn't found, right? Not quite -- load-user-init-file *already* sets the variable to a specific value, and the value is wrong. This patch changes the specific value from the wrong value to the correct value. > How hard can it be to do that after load-user-init-file returns and > reports a failure? I do not know how to do this, because it doesn't seem to me that load-user-init-file reports failures at all. Instead, it handles them itself. Hence why changing load-user-init-file is required. > Or do that inside the function, but only if it processes early-init > file specifically? I really thought that this was exactly what my patch did. There are exactly two places where this internal function is called, and checking whether the optional argument is provided is the way to tell whether the early init-file is being processed. --- In conclusion, if I remove all the changes in this patch except for the '(setq user-init-file ...)' line, would you accept that? Best, Radon --000000000000cbf6580581923a8c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> you've modified the API of load-user-init-fi= le

But we have never released a version of Emacs that include= s this
function -- and it's an internal function. There are o= nly two callers
of this function that exist, and they are both to= uched by this patch.

But, okay, the only reason I changed the= arguments was because I
thought it was an improvement. Would you= accept a patch that fixed
this bug without changing the argument= s?

> All you want is to set a single variable to a specifi= c value if the
> file wasn't found, right?

N= ot quite -- load-user-init-file *already* sets the variable to a
= specific value, and the value is wrong. This patch changes the
sp= ecific value from the wrong value to the correct value.

> = How hard can it be to do that after load-user-init-file returns and
> reports a failure?

I do not know how to do this, beca= use it doesn't seem to me that
load-user-init-file reports fa= ilures at all. Instead, it handles them
itself. Hence why changin= g load-user-init-file is required.

> Or do that inside the= function, but only if it processes early-init
> file specific= ally?

I really thought that this was exactly what my patch di= d. There are
exactly two places where this internal function is c= alled, and
checking whether the optional argument is provided is = the way to tell
whether the early init-file is being processed.
---

In conclusion, if I remove all the changes i= n this patch except for
the '(setq user-init-file ...)' l= ine, would you accept that?

Best,
Radon

--000000000000cbf6580581923a8c--