Received: (at 68546) by debbugs.gnu.org; 17 Oct 2024 17:58:01 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Oct 17 13:58:01 2024
Received: from localhost ([127.0.0.1]:35531 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1t1Ul7-000446-E8
for submit <at> debbugs.gnu.org; Thu, 17 Oct 2024 13:58:01 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:20844)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1t1Ul4-00043r-A6
for 68546 <at> debbugs.gnu.org; Thu, 17 Oct 2024 13:57:58 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id B116F100055;
Thu, 17 Oct 2024 13:57:31 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1729187850;
bh=wb5SyZ6M2bBU9ZLtRSesLAQoilIwaMpq3ljFD0o2zqM=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=hpjogX1oSreJWS/g6BxWZvQ+U7JSptqykjju9yM3RANlZQEO08mJVujiaafFzzBeS
TR7Y6C/eKzMTOTdk4kJoYIha3mroDTUwt4JB/ux6lUUiDbY42yzIVHVM92aiBJ1I64
Cttmyo/2/LY1ozvK1TtTFJ348CRWgZ+VoOfzO3U0OsDrxfyN84vlXzRbX1DboF30gu
fIdSLtI7DAIgd8KoWXX/MwaobrfmBP6EEMIC9/pGkX3tG5pRp/Y95EByKkdH4nzG4W
Aenl0BPEUSsq5OIvU/kd+ejE4Gk9NVnLFuS+yLGoqpa05xmJYN7l0f8gBbAPU9ZZWB
/B2taeewb1Mrg==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id E2216100042;
Thu, 17 Oct 2024 13:57:30 -0400 (EDT)
Received: from alfajor (unknown [23.233.149.155])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id B913412041B;
Thu, 17 Oct 2024 13:57:30 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Spencer Baugh <sbaugh@HIDDEN>
Subject: Re: bug#68546: 29.1.90; end-of-file has incorrect data when
signaled within a load
In-Reply-To: <ier7ca9kwi7.fsf@HIDDEN> (Spencer Baugh's message of
"Tue, 15 Oct 2024 15:16:00 -0400")
Message-ID: <jwvmsj2litk.fsf-monnier+emacs@HIDDEN>
References: <ierle8nye6u.fsf@HIDDEN>
<iery1bkysxh.fsf@HIDDEN> <86il2nv9xp.fsf@HIDDEN>
<ier7ca9kwi7.fsf@HIDDEN>
Date: Thu, 17 Oct 2024 13:57:29 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.031 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 68546
Cc: dmitry@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 68546 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> diff --git a/src/lread.c b/src/lread.c
> index 95c6891c205..ec0c68e1843 100644
> --- a/src/lread.c
> +++ b/src/lread.c
> @@ -2329,8 +2329,8 @@ readevalloop_1 (int old)
> static AVOID
> end_of_file_error (void)
> {
> - if (STRINGP (Vload_true_file_name))
> - xsignal1 (Qend_of_file, Vload_true_file_name);
> + if (!NILP (Vread_end_of_file_data))
> + xsignal1 (Qend_of_file, Vread_end_of_file_data);
Hmm... why call it `Vread_end_of_file_name`?
How 'bout something like `read--source`? I suspect it could be useful to
include similar info in other read errors than `Qend_of_file`.
Also it could make sense to allow that var to indicate when we're
reading from a buffer (rather than a file).
> xsignal0 (Qend_of_file);
> }
> @@ -2434,6 +2434,8 @@ readevalloop (Lisp_Object readcharfun,
> while (continue_reading_p)
> {
> specpdl_ref count1 = SPECPDL_INDEX ();
> + if (NILP (Vread_end_of_file_data))
> + specbind (Qread_end_of_file_name, Vload_true_file_name);
Why the `if` condition here? Sounds like it could lead to problems for
nested loads and such.
Stefan
bug-gnu-emacs@HIDDEN:bug#68546; Package emacs.
Full text available.
Received: (at 68546) by debbugs.gnu.org; 15 Oct 2024 19:16:27 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 15 15:16:27 2024
Received: from localhost ([127.0.0.1]:57505 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1t0n1u-0004az-Ru
for submit <at> debbugs.gnu.org; Tue, 15 Oct 2024 15:16:27 -0400
Received: from mxout6.mail.janestreet.com ([64.215.233.21]:41753)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <sbaugh@HIDDEN>) id 1t0n1s-0004aV-C6
for 68546 <at> debbugs.gnu.org; Tue, 15 Oct 2024 15:16:25 -0400
From: Spencer Baugh <sbaugh@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#68546: 29.1.90; end-of-file has incorrect data when
signaled within a load
In-Reply-To: <86il2nv9xp.fsf@HIDDEN> (Eli Zaretskii's message of "Sat, 17 Feb
2024 09:14:58 +0200")
References: <ierle8nye6u.fsf@HIDDEN>
<iery1bkysxh.fsf@HIDDEN> <86il2nv9xp.fsf@HIDDEN>
Date: Tue, 15 Oct 2024 15:16:00 -0400
Message-ID: <ier7ca9kwi7.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com;
s=waixah; t=1729019760;
bh=4pDmav0+V8BSichL52AvvCJXFfjrd8aTweaUgAONqRo=;
h=From:To:Cc:Subject:In-Reply-To:References:Date;
b=1td6fK38n+5DCyxS76WSrnen2RfzoTa17c9JrsuBnFnjAl7SdOZ0QrxtJ9xg+EuoR
9mOOQgoEng7eVUck3GzpzSUi2wxwLnNZtkXgmBmAI85d04CxYbVHhr05jdBByV7tNV
M0F+VW4+bVhmnDok54Wmp0esFPHfdJ1402BR2tPldktPoq/tuwG34PHXycpGairfwU
HHZq+/g731045SNe1IBofVhYoXIs/0I1Ja7vQjsrUundC7sXTkAOdwdcG+LhoeXe9/
Vh9mHSsboZK2l0PEuXrDNQhWbJ2hsfQOFQceEdQRGXjux+EiPhlNdLZPHtcL3G2s3d
cSb1FfNBioazg==
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 68546
Cc: dmitry@HIDDEN, Stefan Monnier <monnier@HIDDEN>,
68546 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
--=-=-=
Content-Type: text/plain
Eli Zaretskii <eliz@HIDDEN> writes:
>> Cc: dmitry@HIDDEN
>> From: Spencer Baugh <sbaugh@HIDDEN>
>> Date: Fri, 16 Feb 2024 16:56:26 -0500
>>
>> Here is a straightforward fix.
>
> Adding Stefan to the discussion, since this is no longer specific to
> project.el. Stefan, any comments?
>
>> >From d850108fa309701e4899dfbcfd5a20d1e17f86af Mon Sep 17 00:00:00 2001
>> From: Spencer Baugh <sbaugh@HIDDEN>
>> Date: Fri, 16 Feb 2024 16:53:28 -0500
>> Subject: [PATCH] Prevent incorrect error message when calling read inside load
>>
>> Previously, if `load' eval'd a `read' expression which raised
>> end-of-file, the error would include load-true-file-name, even
>> though the `read' may be reading something completely different.
>>
>> Now, end-of-file errors raised by `read' will only include
>> load-true-file-name if it's actually reading that file.
>>
>> We do this by having read include read-end-of-file-name in the error
>> instead of load-true-file-name, and only binding read-end-of-file-name
>> around the "read" parts of readevalloop, not the "eval" parts.
>> (load-true-file-name is still bound throughout)
>>
>> Also, when reading a file (or some other source), it is now
>> possible to bind read-end-of-file-name so that end-of-file
>> errors raised by read will include the filename (or the string
>> of your choice). Previously, an end-of-file error raised by
>> read outside of load would never include the filename.
>
> This needs the obvious documentation changes.
Yes, will update the Elisp manual and NEWS in the next version if this
approach is acceptable.
> Also, I'm not sure I understand the rationale well enough: what other
> use cases do we envision where read-end-of-file-name will be bound to
> some other string than the name of the file being read? IOW, this is
> a general infrastructure change, but the use cases that justify such
> generality are not clear to me.
Anything that uses read can use this to provide more useful error data
and error messages.
Picking a random example, package-load-descriptor calls read on a buffer
containing data from a specific file. Right now, if that read
encounters an error, it will (signal end-of-file nil). If
package-load-descriptor bound read-end-of-file-data to the filename
around the "read" call, read will (signal end-of-file the-filename),
which will provide a much more useful error message.
This could be done with condition-case and re-raising errors, but that
would make stack-traces and debugging worse.
Or we could do it by extracting the filename out of the buffer being
read, but that won't work for e.g. reading strings.
>> --- a/src/lread.c
>> +++ b/src/lread.c
>> @@ -2385,8 +2385,8 @@ readevalloop_1 (int old)
>> static AVOID
>> end_of_file_error (void)
>> {
>> - if (STRINGP (Vload_true_file_name))
>> - xsignal1 (Qend_of_file, Vload_true_file_name);
>> + if (!NILP (Vread_end_of_file_name))
>> + xsignal1 (Qend_of_file, Vread_end_of_file_name);
>
> Why !NILP instead of STRINGP? read-end-of-file-name is documented to
> take string values.
True. I've changed it to read-end-of-file-data in the latest version of
my patch, which seems more generally useful.
>>
>> xsignal0 (Qend_of_file);
>> }
>> @@ -2490,6 +2490,8 @@ readevalloop (Lisp_Object readcharfun,
>> while (continue_reading_p)
>> {
>> specpdl_ref count1 = SPECPDL_INDEX ();
>> + if (NILP (Vread_end_of_file_name))
>> + specbind (Qread_end_of_file_name, Vload_true_file_name);
>>
>> if (b != 0 && !BUFFER_LIVE_P (b))
>> error ("Reading from killed buffer");
>> @@ -2585,7 +2587,7 @@ readevalloop (Lisp_Object readcharfun,
>> if (!NILP (start) && continue_reading_p)
>> start = Fpoint_marker ();
>>
>> - /* Restore saved point and BEGV. */
>> + /* Restore saved point and BEGV, and unbind read_stream_for_error. */
>
> read_stream_for_error or read-end-of-file-name? If the former, I
> don't understand the rationale for this hunk.
Fixed, yes, it should have been read-end-of-file-name.
>> + DEFVAR_LISP ("read-end-of-file-name", Vread_end_of_file_name,
>> + doc: /* String to be included when `read' signals `end-of-file'.
> ^^^^^^^^^^^^^^
> "included" where? This sentence needs to be clarified, either in it
> or in the following text.
Fixed.
> Also, the general nature of the feature is not reflected in the
> variable's name: if this can be any string, why does it have
> "file-name" in its name?
True, changed to read-end-of-file-data to make it more clear.
--=-=-=
Content-Type: text/x-patch
Content-Disposition: inline;
filename=0001-Prevent-incorrect-error-message-when-calling-read-in.patch
From 8b308258a0deafcfa3846c52efc651f09154ea9e Mon Sep 17 00:00:00 2001
From: Spencer Baugh <sbaugh@HIDDEN>
Date: Tue, 15 Oct 2024 15:04:48 -0400
Subject: [PATCH] Prevent incorrect error message when calling read inside load
Previously, if `load' eval'd a `read' expression which raised
end-of-file, the error would include load-true-file-name, even
though the `read' may be reading something completely different.
Now, end-of-file errors raised by `read' will only include
load-true-file-name if it's actually reading that file.
We do this by having read include read-end-of-file-data in the error
instead of load-true-file-name, and only binding read-end-of-file-data
around the "read" parts of readevalloop, not the "eval" parts.
(load-true-file-name is still bound throughout)
Also, when reading a file (or some other source), it is now
possible to bind read-end-of-file-data so that end-of-file
errors raised by read will include the filename (or the string
of your choice). Previously, an end-of-file error raised by
read outside of load would never include the filename.
* src/lread.c (syms_of_lread): Add read-end-of-file-data.
(readevalloop): Bind read-end-of-file-data to
load-true-file-name around read.
(end_of_file_error): Use read-end-of-file-data instead of
load-true-file-name. (bug#68546)
---
src/lread.c | 19 +++++++++++++++----
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/src/lread.c b/src/lread.c
index 95c6891c205..ec0c68e1843 100644
--- a/src/lread.c
+++ b/src/lread.c
@@ -2329,8 +2329,8 @@ readevalloop_1 (int old)
static AVOID
end_of_file_error (void)
{
- if (STRINGP (Vload_true_file_name))
- xsignal1 (Qend_of_file, Vload_true_file_name);
+ if (!NILP (Vread_end_of_file_data))
+ xsignal1 (Qend_of_file, Vread_end_of_file_data);
xsignal0 (Qend_of_file);
}
@@ -2434,6 +2434,8 @@ readevalloop (Lisp_Object readcharfun,
while (continue_reading_p)
{
specpdl_ref count1 = SPECPDL_INDEX ();
+ if (NILP (Vread_end_of_file_data))
+ specbind (Qread_end_of_file_name, Vload_true_file_name);
if (b != 0 && !BUFFER_LIVE_P (b))
error ("Reading from killed buffer");
@@ -2529,7 +2531,7 @@ readevalloop (Lisp_Object readcharfun,
if (!NILP (start) && continue_reading_p)
start = Fpoint_marker ();
- /* Restore saved point and BEGV. */
+ /* Restore saved point and BEGV, and unbind read_end_of_file_data. */
unbind_to (count1, Qnil);
/* Now eval what we just read. */
@@ -2661,7 +2663,10 @@ DEFUN ("read", Fread, Sread, 0, 1, 0,
call it with a char as argument to push a char back)
a string (takes text from string, starting at the beginning)
t (read text line using minibuffer and use it, or read from
- standard input in batch mode). */)
+ standard input in batch mode).
+
+If an unterminated list, vector, or string is encountered, signal
+`end-of-file' with `read-end-of-file-data'. */)
(Lisp_Object stream)
{
if (NILP (stream))
@@ -5963,6 +5968,12 @@ syms_of_lread (void)
doc: /* Full name of file being loaded by `load'. */);
Vload_true_file_name = Qnil;
+ DEFVAR_LISP ("read-end-of-file-data", Vread_end_of_file_data,
+ doc: /* When `read' signals `end-of-file', it passes this to `signal' as DATA.
+When loading a file, this is bound to `load-true-file-name'. */);
+ Vread_end_of_file_data = Qnil;
+ DEFSYM (Qread_end_of_file_data, "read-end-of-file-data");
+
DEFVAR_LISP ("user-init-file", Vuser_init_file,
doc: /* File name, including directory, of user's initialization file.
If the file loaded had extension `.elc', and the corresponding source file
--
2.39.3
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#68546; Package emacs.
Full text available.
Received: (at 68546) by debbugs.gnu.org; 17 Feb 2024 07:17:42 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Feb 17 02:17:42 2024
Received: from localhost ([127.0.0.1]:60359 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rbExB-0003es-OZ
for submit <at> debbugs.gnu.org; Sat, 17 Feb 2024 02:17:42 -0500
Received: from eggs.gnu.org ([209.51.188.92]:53474)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <eliz@HIDDEN>) id 1rbEx7-0003ec-C6
for 68546 <at> debbugs.gnu.org; Sat, 17 Feb 2024 02:17:41 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
id 1rbEub-0004Rd-JX; Sat, 17 Feb 2024 02:15:01 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
mime-version; bh=ZKTLhtHSkCbC8ig0wpQkklcbdxR4qguJoIaZirOUFPY=; b=XF/2KQoS1Vls
FJD7at2QA57yGaFE01r5nhtCf34NWeKgJKg2pvLxgYjy2hNyDtWcjqU83F3YHEIv6nJk2KRZZX/MG
pUTMVpRZprkEnFO7/SsRq1JMnn6ACJ5KhwzHPZ960EfsqfFj1u9663G8x9jDd3Nc0jdJhmsNGRMCe
oaUve+05av/rGtPMyvf0DMN0RXIZ9s1tF6W29EjviuVeA82XrHRCEcY+l8b4A43D0dG50BwqOJvVI
ihPYVQ7L5AG9kFZyN4YmSF2/f0ZSCMn08bvqXbOu+ubXxkAwXlEbI4Lw1WpIDZ2ZNT2VdtKGoiDR6
aJxIXgxqbD9SnwfrLBhE+Q==;
Date: Sat, 17 Feb 2024 09:14:58 +0200
Message-Id: <86il2nv9xp.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Spencer Baugh <sbaugh@HIDDEN>,
Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <iery1bkysxh.fsf@HIDDEN> (message from Spencer Baugh on
Fri, 16 Feb 2024 16:56:26 -0500)
Subject: Re: bug#68546: 29.1.90;
end-of-file has incorrect data when signaled within a load
References: <ierle8nye6u.fsf@HIDDEN>
<iery1bkysxh.fsf@HIDDEN>
X-Spam-Score: -4.2 (----)
X-Debbugs-Envelope-To: 68546
Cc: dmitry@HIDDEN, 68546 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.2 (-----)
> Cc: dmitry@HIDDEN
> From: Spencer Baugh <sbaugh@HIDDEN>
> Date: Fri, 16 Feb 2024 16:56:26 -0500
>
> Here is a straightforward fix.
Adding Stefan to the discussion, since this is no longer specific to
project.el. Stefan, any comments?
> >From d850108fa309701e4899dfbcfd5a20d1e17f86af Mon Sep 17 00:00:00 2001
> From: Spencer Baugh <sbaugh@HIDDEN>
> Date: Fri, 16 Feb 2024 16:53:28 -0500
> Subject: [PATCH] Prevent incorrect error message when calling read inside load
>
> Previously, if `load' eval'd a `read' expression which raised
> end-of-file, the error would include load-true-file-name, even
> though the `read' may be reading something completely different.
>
> Now, end-of-file errors raised by `read' will only include
> load-true-file-name if it's actually reading that file.
>
> We do this by having read include read-end-of-file-name in the error
> instead of load-true-file-name, and only binding read-end-of-file-name
> around the "read" parts of readevalloop, not the "eval" parts.
> (load-true-file-name is still bound throughout)
>
> Also, when reading a file (or some other source), it is now
> possible to bind read-end-of-file-name so that end-of-file
> errors raised by read will include the filename (or the string
> of your choice). Previously, an end-of-file error raised by
> read outside of load would never include the filename.
This needs the obvious documentation changes.
Also, I'm not sure I understand the rationale well enough: what other
use cases do we envision where read-end-of-file-name will be bound to
some other string than the name of the file being read? IOW, this is
a general infrastructure change, but the use cases that justify such
generality are not clear to me.
> --- a/src/lread.c
> +++ b/src/lread.c
> @@ -2385,8 +2385,8 @@ readevalloop_1 (int old)
> static AVOID
> end_of_file_error (void)
> {
> - if (STRINGP (Vload_true_file_name))
> - xsignal1 (Qend_of_file, Vload_true_file_name);
> + if (!NILP (Vread_end_of_file_name))
> + xsignal1 (Qend_of_file, Vread_end_of_file_name);
Why !NILP instead of STRINGP? read-end-of-file-name is documented to
take string values.
>
> xsignal0 (Qend_of_file);
> }
> @@ -2490,6 +2490,8 @@ readevalloop (Lisp_Object readcharfun,
> while (continue_reading_p)
> {
> specpdl_ref count1 = SPECPDL_INDEX ();
> + if (NILP (Vread_end_of_file_name))
> + specbind (Qread_end_of_file_name, Vload_true_file_name);
>
> if (b != 0 && !BUFFER_LIVE_P (b))
> error ("Reading from killed buffer");
> @@ -2585,7 +2587,7 @@ readevalloop (Lisp_Object readcharfun,
> if (!NILP (start) && continue_reading_p)
> start = Fpoint_marker ();
>
> - /* Restore saved point and BEGV. */
> + /* Restore saved point and BEGV, and unbind read_stream_for_error. */
read_stream_for_error or read-end-of-file-name? If the former, I
don't understand the rationale for this hunk.
> + DEFVAR_LISP ("read-end-of-file-name", Vread_end_of_file_name,
> + doc: /* String to be included when `read' signals `end-of-file'.
^^^^^^^^^^^^^^
"included" where? This sentence needs to be clarified, either in it
or in the following text.
Also, the general nature of the feature is not reflected in the
variable's name: if this can be any string, why does it have
"file-name" in its name?
Thanks.
bug-gnu-emacs@HIDDEN:bug#68546; Package emacs.
Full text available.
Received: (at 68546) by debbugs.gnu.org; 16 Feb 2024 21:56:55 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Feb 16 16:56:55 2024
Received: from localhost ([127.0.0.1]:60300 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rb6CV-00037f-4w
for submit <at> debbugs.gnu.org; Fri, 16 Feb 2024 16:56:55 -0500
Received: from mxout5.mail.janestreet.com ([64.215.233.18]:42185)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <sbaugh@HIDDEN>) id 1rb6CS-00037S-LZ
for 68546 <at> debbugs.gnu.org; Fri, 16 Feb 2024 16:56:53 -0500
From: Spencer Baugh <sbaugh@HIDDEN>
To: 68546 <at> debbugs.gnu.org
Subject: Re: bug#68546: 29.1.90; end-of-file has incorrect data when
signaled within a load
In-Reply-To: <ierle8nye6u.fsf@HIDDEN>
(Spencer Baugh's message of "Wed, 17 Jan 2024 14:04:09 -0500")
References: <ierle8nye6u.fsf@HIDDEN>
Date: Fri, 16 Feb 2024 16:56:26 -0500
Message-ID: <iery1bkysxh.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com;
s=waixah; t=1708120587;
bh=HHMKD51uUjskJ8tLiOP6uDYAEvZzbo0+Yi0nZt5GmAw=;
h=From:To:Cc:Subject:In-Reply-To:References:Date;
b=3Gh7MCz8hZK0HxgxLYWeM9oaAJpENMWqQWQX0XUL41DC5F0OCtexkTp2VYtqev3Zo
Cq/64ehO7BOWeNbL9b481oA0v/j5oVTjDCrH8LPH1YBs5BGSY4gP7fPwvoeMXtBFj/
9mwpc3k3ULn16+4sxx+FjGpfgtI7gwqbi2z0fxxsRI1Ho/fkvkUGB9b+su7dqkmaq4
M9ad48s0diKVJ1GQxIEB7bGC5DMZLRwefKoZYjxzfP8u8YyTM97w8mszVRD3a5qXGg
NpYYJDsRlQXv8cjH96sCE0x0BpeZjyylCjtMChDLcg7jl+s/xQKczjFyY+Dc8Zln1q
K9kCHAWIJRpPQ==
X-Spam-Score: -1.9 (-)
X-Debbugs-Envelope-To: 68546
Cc: dmitry@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.9 (--)
--=-=-=
Content-Type: text/plain
Here is a straightforward fix.
--=-=-=
Content-Type: text/x-patch
Content-Disposition: inline;
filename=0001-Prevent-incorrect-error-message-when-calling-read-in.patch
From d850108fa309701e4899dfbcfd5a20d1e17f86af Mon Sep 17 00:00:00 2001
From: Spencer Baugh <sbaugh@HIDDEN>
Date: Fri, 16 Feb 2024 16:53:28 -0500
Subject: [PATCH] Prevent incorrect error message when calling read inside load
Previously, if `load' eval'd a `read' expression which raised
end-of-file, the error would include load-true-file-name, even
though the `read' may be reading something completely different.
Now, end-of-file errors raised by `read' will only include
load-true-file-name if it's actually reading that file.
We do this by having read include read-end-of-file-name in the error
instead of load-true-file-name, and only binding read-end-of-file-name
around the "read" parts of readevalloop, not the "eval" parts.
(load-true-file-name is still bound throughout)
Also, when reading a file (or some other source), it is now
possible to bind read-end-of-file-name so that end-of-file
errors raised by read will include the filename (or the string
of your choice). Previously, an end-of-file error raised by
read outside of load would never include the filename.
* src/lread.c (syms_of_lread): Add read-end-of-file-name.
(readevalloop): Bind read-end-of-file-name to
load-true-file-name around read.
(end_of_file_error): Use read-end-of-file-name instead of
load-true-file-name. (bug#68546)
---
src/lread.c | 14 +++++++++++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/src/lread.c b/src/lread.c
index 0e67a3f8879..54ae88c7eab 100644
--- a/src/lread.c
+++ b/src/lread.c
@@ -2385,8 +2385,8 @@ readevalloop_1 (int old)
static AVOID
end_of_file_error (void)
{
- if (STRINGP (Vload_true_file_name))
- xsignal1 (Qend_of_file, Vload_true_file_name);
+ if (!NILP (Vread_end_of_file_name))
+ xsignal1 (Qend_of_file, Vread_end_of_file_name);
xsignal0 (Qend_of_file);
}
@@ -2490,6 +2490,8 @@ readevalloop (Lisp_Object readcharfun,
while (continue_reading_p)
{
specpdl_ref count1 = SPECPDL_INDEX ();
+ if (NILP (Vread_end_of_file_name))
+ specbind (Qread_end_of_file_name, Vload_true_file_name);
if (b != 0 && !BUFFER_LIVE_P (b))
error ("Reading from killed buffer");
@@ -2585,7 +2587,7 @@ readevalloop (Lisp_Object readcharfun,
if (!NILP (start) && continue_reading_p)
start = Fpoint_marker ();
- /* Restore saved point and BEGV. */
+ /* Restore saved point and BEGV, and unbind read_stream_for_error. */
unbind_to (count1, Qnil);
/* Now eval what we just read. */
@@ -5843,6 +5845,12 @@ syms_of_lread (void)
doc: /* Full name of file being loaded by `load'. */);
Vload_true_file_name = Qnil;
+ DEFVAR_LISP ("read-end-of-file-name", Vread_end_of_file_name,
+ doc: /* String to be included when `read' signals `end-of-file'.
+When loading a file, this is bound to the filename. */);
+ Vread_end_of_file_name = Qnil;
+ DEFSYM (Qread_end_of_file_name, "read-end-of-file-name");
+
DEFVAR_LISP ("user-init-file", Vuser_init_file,
doc: /* File name, including directory, of user's initialization file.
If the file loaded had extension `.elc', and the corresponding source file
--
2.39.3
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#68546; Package emacs.
Full text available.Received: (at 68546) by debbugs.gnu.org; 26 Jan 2024 00:56:11 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 25 19:56:11 2024 Received: from localhost ([127.0.0.1]:49681 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rTAVr-00024e-6c for submit <at> debbugs.gnu.org; Thu, 25 Jan 2024 19:56:11 -0500 Received: from out3-smtp.messagingengine.com ([66.111.4.27]:40105) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <dmitry@HIDDEN>) id 1rTAVp-00023g-4F for 68546 <at> debbugs.gnu.org; Thu, 25 Jan 2024 19:56:05 -0500 Received: from compute7.internal (compute7.nyi.internal [10.202.2.48]) by mailout.nyi.internal (Postfix) with ESMTP id CA9B25C0066; Thu, 25 Jan 2024 19:55:53 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Thu, 25 Jan 2024 19:55:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1706230553; x=1706316953; bh=olTCSSj0seK61PfSl8JL9pGtPawfdH44o9RU0T2DFpk=; b= Whu9WZA/r4rd/+d20LWDBQfhLKu8KqLFKTleMpfYJJye59xnuk7DjkNtJHDG+db5 tHrQQNKA2XsqY8mhPY7/2c6wfFpLi3bzCePTQvonBNAQAwe9891cO7r6PMeaP7Jn UzotCx/gJ9WygpDtc+Qq/mvQbLGX4ebKAms/1v6ZyYSQ4HwQz106hlKdUQ6bKVKp WeXRGnLhhtjXv5APv+PY0lkQ6DDbAr0+38GZBtgX1b5gTKbMkVze2X8ikrrJTIeh dPKJBaekNJBxThN+4rSsNbJl8lhFKzYVev0a9hVuneXFJU4hk8vlLL60aBZ0F0ae g38Uz7e0zSAQnvXcqip8cg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1706230553; x= 1706316953; bh=olTCSSj0seK61PfSl8JL9pGtPawfdH44o9RU0T2DFpk=; b=W 3eTX6Swev32h5grthmtZsEaBjiVKmMQJjW30gDSfasZnryWxoEpZm31zkTf6O+tT x/FmOwZUlhXR9dDLozNZZdY8v9Ao5ARon6PH3so4mGkMsw3VfeN3mcvjYE7TAOie Ez90Tsm1zmYyaPuti9f8g79/P2HnohO2Rl1cF9D9IA0MW36BISpJmyG9nEFlFm2M GgsTndyV4hlFmmCYvOvED87FuK56X5gYAF/cALB1vwDY3GIYW0691D6oFoY48Yjq PKXFcfYKI/ZoHUyQ4S2Ag0vDoCmTJqlN1ogkHTj5xwimTiftKiZMeoF4Y+m0Qr3R gH087oGEv5SXvJWtitLmA== X-ME-Sender: <xms:GQOzZZeWfFulzCEGHdqWB_DDNJ32z1NW2aycWKxM2odMYsnAlfuBuA> <xme:GQOzZXPkgfBW2nDBIwzrvcMYDCeb2PBtX6zQd9cL3_QVwVT3F7tyauR2f6kAvyGia mOvBH0MKY-HSWuBi38> X-ME-Received: <xmr:GQOzZSjv8WW3Zq0W_iHCjgbA0u-upW1vVAAFpKaYcgrUnnrg-r8Tat32wUNldKqzptWNmw> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdeliedgvdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtvdejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepgeelfeetkefghfdvhfdtgeevveevteetgeetveegtedthefhudekteehffeu keeknecuvehluhhsthgvrhfuihiivgepudenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: <xmx:GQOzZS8wpDLcJ6h7nRRF0_jGX9OAg_2gmheGcmiMiJpLbBtu4lxp7A> <xmx:GQOzZVuCynwtOq1kWTRIFBEiOH86i2psrj0w5Hofc7Xr7YeLE_s7Zg> <xmx:GQOzZRHfIar8yPjZHkCgUS5H3hQQrOtdkzjquBTXC_HuNdXH0P7dBw> <xmx:GQOzZT3JzvhgG7XueA8gupcFmQcS83IxThu44Kn0xL7qnKIOtCQKWw> Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 25 Jan 2024 19:55:52 -0500 (EST) Message-ID: <84173d7b-2687-4384-8c1c-3fc65e62b9d6@HIDDEN> Date: Fri, 26 Jan 2024 02:55:52 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#68546: 29.1.90; end-of-file has incorrect data when signaled within a load Content-Language: en-US To: Spencer Baugh <sbaugh@HIDDEN> References: <ierle8nye6u.fsf@HIDDEN> <797f3211-068f-4b7f-bb34-f3c9ee12241b@HIDDEN> <CAO=BR8O9zkOhuhc+3tWdaSW_B3LSgxfb=q_ywKZJn5ypyMSqnw@HIDDEN> <CAO=BR8MgGZzvou4jvosF78tQuuysiwVnTNnJEGKLxe=NqjbAVg@HIDDEN> From: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <CAO=BR8MgGZzvou4jvosF78tQuuysiwVnTNnJEGKLxe=NqjbAVg@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 68546 Cc: 68546 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On 25/01/2024 16:12, Spencer Baugh wrote: > Ah, I think the cause (in at least one case) is that the user ran out of > disk space, and so the write-region call in project--write-project-list > failed when writing, which happens after truncating the existing file. Makes sense. > I > guess there should be some atomic version of write-region which writes > to a temp file and renames it over the original. Yep, that would be an improvement.
bug-gnu-emacs@HIDDEN:bug#68546; Package emacs.
Full text available.Received: (at 68546) by debbugs.gnu.org; 26 Jan 2024 00:54:40 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 25 19:54:40 2024 Received: from localhost ([127.0.0.1]:49670 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rTAUS-00021H-6J for submit <at> debbugs.gnu.org; Thu, 25 Jan 2024 19:54:40 -0500 Received: from out3-smtp.messagingengine.com ([66.111.4.27]:56179) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <dmitry@HIDDEN>) id 1rTAUR-000212-8r for 68546 <at> debbugs.gnu.org; Thu, 25 Jan 2024 19:54:39 -0500 Received: from compute7.internal (compute7.nyi.internal [10.202.2.48]) by mailout.nyi.internal (Postfix) with ESMTP id EEFB65C00C6; Thu, 25 Jan 2024 19:54:27 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Thu, 25 Jan 2024 19:54:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1706230467; x=1706316867; bh=uQT+jBzurnP2+SOUW0wyFJS3tgfehbvCCpiifkeuykU=; b= qPp9a1PkfC4ZUb7ntx/J7qJg7BrEoRUZJoAn9hOz0l0I6tA94qUZvF2EwrMNg8Qa xSojyxDZp5R9cwossxJwDmuRrSdnZAsEhKdzKiq9bO6UycJ8TZIfK3zEjOYSnVjL kDOm4Ak+xhCvbG03IsLr/W6423MedsuK8OKTcLl4Xp8CrLnVHR/JvD2/CumEB7Ii 9bU6GCtb9Wbp8Q86M7hhPhhU31WWEI2cbfaWkTPWWK44smP8UaURONeqBLibwX8g MtdEqg108HFbaPZVcVnn6slIcVFLnzdB2XlCMtiaGHqk/caekPSbhyVnyhIaDNsH Tjv1nDgPy6oE+cwm3yFErQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1706230467; x= 1706316867; bh=uQT+jBzurnP2+SOUW0wyFJS3tgfehbvCCpiifkeuykU=; b=y ylc6qmRdbbkQkHhr0d/zcc1jL0ZZAsiCcLZ6bICLglrEsySl5eQLIJKZcIyXmpn2 RGup8boHKp+wABkvyAJkPtJ6MT2A3dh9HbobT/yVYfLorVDEClumU4VBRUuUMuRJ 7TEM/fQiUvv+LNArXJ3ObwEsanOtWrrZziYdIL/SkK3vbOCo7vtz58T7YxzFbncj aFPxBR++bRxQk17rnCGGPMavdhDmOpqcG9KQnUziram6d0P2l9OGDdRszdd0RS6O MC7/ZQXwxFxDfA9a218WGpOJ9fMFx8Fx2K0kftgWWR1ZqWPZDTqp9Er/ow0A55vr ozz9soSRekVghHrsJhBaA== X-ME-Sender: <xms:wwKzZYX9NWt_a79d8E4hNC9jgnEmbywBqF6swKvFEmmaBgcub9uhpw> <xme:wwKzZcmLVHzoqBi4Vi2giiy96XVuXUuIf1UlLp-6yhO7SgbXYa30xZAZIMetyEd4p tjqUmPRa4sEy7Rm6tk> X-ME-Received: <xmr:wwKzZcZyQgiOJFqLZK3zaWY2uomvfjV9nKUvaLvPM6g5Y5qmMd7zZ1w1IWBps40IU05Udw> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdeliedgvdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtkeertddtvdejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepgeelfeetkefghfdvhfdtgeevveevteetgeetveegtedthefhudekteehffeu keeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: <xmx:wwKzZXUu1P5W9OOkRhVE-CYhrO2vpXGeq-OP8plq0r0BO0FCc9qeEw> <xmx:wwKzZSmqNKicNj9g_FZDRzYCR7y8iclHkLK_ZeuCqPzY7SGUw9yQPw> <xmx:wwKzZcfl_9valBdb-NVT9DwRn5Cj9SJgsnlGUrOVyCKDY6KSUEv4Dg> <xmx:wwKzZZvixA6QNHZ8trjqyqboGNANjhMID-KjFBuw6oWsZuCJH8aAiA> Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 25 Jan 2024 19:54:26 -0500 (EST) Message-ID: <f3b88ff9-ed9d-4c1f-8643-e9533ba78035@HIDDEN> Date: Fri, 26 Jan 2024 02:54:25 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#68546: 29.1.90; end-of-file has incorrect data when signaled within a load Content-Language: en-US To: Spencer Baugh <sbaugh@HIDDEN> References: <ierle8nye6u.fsf@HIDDEN> <797f3211-068f-4b7f-bb34-f3c9ee12241b@HIDDEN> <CAO=BR8O9zkOhuhc+3tWdaSW_B3LSgxfb=q_ywKZJn5ypyMSqnw@HIDDEN> From: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <CAO=BR8O9zkOhuhc+3tWdaSW_B3LSgxfb=q_ywKZJn5ypyMSqnw@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 68546 Cc: 68546 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On 25/01/2024 16:05, Spencer Baugh wrote: > Yes, I think that would be great. Especially because this allows > startup to continue. If it's okay with you too, I think it's reasonable > to push. Now pushed, thanks. I'm not closing the bug, it's up to you to decide whether there's more to be done.
bug-gnu-emacs@HIDDEN:bug#68546; Package emacs.
Full text available.Received: (at 68546) by debbugs.gnu.org; 26 Jan 2024 00:45:43 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 25 19:45:43 2024 Received: from localhost ([127.0.0.1]:49657 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rTALm-0001gS-VN for submit <at> debbugs.gnu.org; Thu, 25 Jan 2024 19:45:43 -0500 Received: from out3-smtp.messagingengine.com ([66.111.4.27]:36453) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <dmitry@HIDDEN>) id 1rTALk-0001gE-Vq for 68546 <at> debbugs.gnu.org; Thu, 25 Jan 2024 19:45:41 -0500 Received: from compute7.internal (compute7.nyi.internal [10.202.2.48]) by mailout.nyi.internal (Postfix) with ESMTP id 9E55C5C00AB; Thu, 25 Jan 2024 19:45:29 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Thu, 25 Jan 2024 19:45:29 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1706229929; x=1706316329; bh=eL5kMsf6yP3rix4/XSYKIVyPjRDtBJDcVXKCK5/EEbo=; b= WriioxkNEOr+OkNPH/6dewJ1U0nMyTPQgjoxlXCW+BkfYj9Y+3OYuNWFvDYiUHwx hkD4vz3BO/ZpZkrRhzsTHTn2Q//l1P3NyfMtkakVTVrox6dtwArq8DEpQsjc5OOu Fj2jWuG9qLrSlJXaCkJH21udDRRYJl66E4i+fCEAXs2wPZf1QwTsZ7/smm4D+tVM lH16KLSp928GcWmJAJpGXKJchQ0T1bVuwIIbqGPmuKGNBxui1x/En6GFAVZ0M2Ox z+pqYm0m5SC+EsUZHEPztcoi1A4+QKkxuT+VsP6BMtPNDOoLqJsV1aoem1ebtmM1 418js+ht9rnKpyWlbNq29w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1706229929; x= 1706316329; bh=eL5kMsf6yP3rix4/XSYKIVyPjRDtBJDcVXKCK5/EEbo=; b=e l6+3Ue64nBHXpP9FpEM0YMdT8TrOh8ffsHnM21OoDUmYM7boEJo2v/Kne97ghCAD gXkW85td4UTcU7iFNczDEhnQitnYHH6lqvFYlNaotD2QZigQ91IZAnQ0CCgHIXkE n9CK4suaW3Sqq8+v4cnCOxXMOgIEgZ+GOUgp81x7EX3JwMAsWLBI+r7S0PFGZ+wP b6F8HBlLezNXInDiuZI7RAhabjYbjzOQ8+qIUEq0Y4DQ11WeihgWgzl877JgcTdv 5o5vIUTv1tHuH+L1/+NVja46LwuM18qhdLEpnTSMBlbFMwQeM12rMf0QxqzTcjOK dTcWjqMBzPptTJrgfKoNw== X-ME-Sender: <xms:qQCzZapfHymy9WQqdXno3VB3vA8iiwr4s0fFw8ps-Jq5oWU-2C1qHA> <xme:qQCzZYqT_JbkJPlBEL768ga1Z2e2GC7I7JwCxxDM8eyUthN5qW20QX3pXroZwFj4x bi7oG4J58tx0tI4RyE> X-ME-Received: <xmr:qQCzZfMlsdws00A3ePzBT4JDZBaiXbhMeLhEobzFBeRmfkJeUruDqqtYGJs0ZHI474kB_A> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdeliedgvdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdejnecuhfhrohhmpeffmhhi thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth htvghrnhepteduleejgeehtefgheegjeekueehvdevieekueeftddvtdevfefhvdevgedu jeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepug hmihhtrhihsehguhhtohhvrdguvghv X-ME-Proxy: <xmx:qQCzZZ7mbBpsDt5ZjXXCZ-Qo6Ith1lQJpkoy_z_vPxEwYK_Tr1RILA> <xmx:qQCzZZ7pe_HcsO08r3YxzIEV95x4XTQyK7pITFRB-t8OzjioQTGvXg> <xmx:qQCzZZgINQirvnLnA2SeUE_Xod1xB3jYhM2nlZ9-Gr2H2WYiZNqpvg> <xmx:qQCzZbTncp2TToz4wtkjhOgDDEbnE3MqrMVL_LVnQXepdOtMYHo3fQ> Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 25 Jan 2024 19:45:28 -0500 (EST) Message-ID: <1e8c06d3-0e6e-49ac-8042-18bb7a0693ef@HIDDEN> Date: Fri, 26 Jan 2024 02:45:28 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#68546: 29.1.90; end-of-file has incorrect data when signaled within a load Content-Language: en-US To: Eli Zaretskii <eliz@HIDDEN>, Spencer Baugh <sbaugh@HIDDEN> References: <ierle8nye6u.fsf@HIDDEN> <797f3211-068f-4b7f-bb34-f3c9ee12241b@HIDDEN> <CAO=BR8O9zkOhuhc+3tWdaSW_B3LSgxfb=q_ywKZJn5ypyMSqnw@HIDDEN> <86cytpcwqe.fsf@HIDDEN> From: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <86cytpcwqe.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 68546 Cc: 68546 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On 25/01/2024 16:29, Eli Zaretskii wrote: >> Cc:68546 <at> debbugs.gnu.org >> From: Spencer Baugh<sbaugh@HIDDEN> >> Date: Thu, 25 Jan 2024 09:05:19 -0500 >> >> Would something like this help with this particular sub-problem? >> >> diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el >> index a6f14a0865c..196a82757b2 100644 >> --- a/lisp/progmodes/project.el >> +++ b/lisp/progmodes/project.el >> @@ -1694,7 +1694,9 @@ project--read-project-list >> (let ((name (car elem))) >> (list (if (file-remote-p name) name >> (abbreviate-file-name name))))) >> - (read (current-buffer)))))) >> + (condition-case nil >> + (read (current-buffer)) >> + (end-of-file (warn "Failed to read the projects list >> file"))))))) >> (unless (seq-every-p >> (lambda (elt) (stringp (car-safe elt))) >> project--list) >> >> Yes, I think that would be great. Especially because this allows startup to continue. If it's okay with >> you too, I think it's reasonable to push. > I don't object to the change, of course, but perhaps we could make the > error message friendlier? For example: > > Failed to read the projects list file due to unexpected EOF Sure, the patch's message was more of a draft.
bug-gnu-emacs@HIDDEN:bug#68546; Package emacs.
Full text available.Received: (at 68546) by debbugs.gnu.org; 25 Jan 2024 14:29:46 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 25 09:29:46 2024 Received: from localhost ([127.0.0.1]:47687 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rT0ji-0001XD-5T for submit <at> debbugs.gnu.org; Thu, 25 Jan 2024 09:29:46 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:50966) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1rT0jf-0001X1-Jq for 68546 <at> debbugs.gnu.org; Thu, 25 Jan 2024 09:29:44 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1rT0jT-0004oT-PJ; Thu, 25 Jan 2024 09:29:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=1svcCHwaghLmJgO5RgPs/oSrDEVqnTmfkPNIT7rMN6o=; b=KdIEnqer/pNi Y8Pf71cNdQiGgy/dldewp93d2gJLF6zYLv9BSkLwx8/irjn5UEfkFsi9P9i1pp3KGhPVJoGVEDMG5 tiB97P3cgEIVVtbb+wFNIqg6iJepIG8noFFxPb7503MGYObrjw2uMTvh7kGveOptIf87WFN6+QICi U3jlIR6GXyE7M6N/f34TyEMN+TnmlxQlKbxCgC0GgqwOpRUDbysaHj1jO5k1vO5bf5arBF1BQZhDS kOfiTqylq9oj4iTO4CrlYAtbLKtEciRSXiFQHXvvufu9Cc4aegzG7PVgZqfn2efM0wpfbCqxgoStN RPgi4g2jvuxXG2xTVaAp3A==; Date: Thu, 25 Jan 2024 16:29:29 +0200 Message-Id: <86cytpcwqe.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Spencer Baugh <sbaugh@HIDDEN> In-Reply-To: <CAO=BR8O9zkOhuhc+3tWdaSW_B3LSgxfb=q_ywKZJn5ypyMSqnw@HIDDEN> (message from Spencer Baugh on Thu, 25 Jan 2024 09:05:19 -0500) Subject: Re: bug#68546: 29.1.90; end-of-file has incorrect data when signaled within a load References: <ierle8nye6u.fsf@HIDDEN> <797f3211-068f-4b7f-bb34-f3c9ee12241b@HIDDEN> <CAO=BR8O9zkOhuhc+3tWdaSW_B3LSgxfb=q_ywKZJn5ypyMSqnw@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68546 Cc: dmitry@HIDDEN, 68546 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Cc: 68546 <at> debbugs.gnu.org > From: Spencer Baugh <sbaugh@HIDDEN> > Date: Thu, 25 Jan 2024 09:05:19 -0500 > > Would something like this help with this particular sub-problem? > > diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el > index a6f14a0865c..196a82757b2 100644 > --- a/lisp/progmodes/project.el > +++ b/lisp/progmodes/project.el > @@ -1694,7 +1694,9 @@ project--read-project-list > (let ((name (car elem))) > (list (if (file-remote-p name) name > (abbreviate-file-name name))))) > - (read (current-buffer)))))) > + (condition-case nil > + (read (current-buffer)) > + (end-of-file (warn "Failed to read the projects list > file"))))))) > (unless (seq-every-p > (lambda (elt) (stringp (car-safe elt))) > project--list) > > Yes, I think that would be great. Especially because this allows startup to continue. If it's okay with > you too, I think it's reasonable to push. I don't object to the change, of course, but perhaps we could make the error message friendlier? For example: Failed to read the projects list file due to unexpected EOF
bug-gnu-emacs@HIDDEN:bug#68546; Package emacs.
Full text available.Received: (at 68546) by debbugs.gnu.org; 25 Jan 2024 14:13:16 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 25 09:13:16 2024 Received: from localhost ([127.0.0.1]:47674 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rT0Tj-00018x-WA for submit <at> debbugs.gnu.org; Thu, 25 Jan 2024 09:13:16 -0500 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:49619) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <sbaugh@HIDDEN>) id 1rT0Ti-00018d-E3 for 68546 <at> debbugs.gnu.org; Thu, 25 Jan 2024 09:13:15 -0500 Received: from mail-ej1-f69.google.com ([209.85.218.69]) by mxgoog2.mail.janestreet.com with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128) (Exim 4.97.1) id 1rT0TY-0000000BNNu-19jR for 68546 <at> debbugs.gnu.org; Thu, 25 Jan 2024 09:13:02 -0500 Received: by mail-ej1-f69.google.com with SMTP id a640c23a62f3a-a2f1d0c3389so247036066b.0 for <68546 <at> debbugs.gnu.org>; Thu, 25 Jan 2024 06:13:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=google; t=1706191982; x=1706796782; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=2GKDcVy4qEfl0MBhRgumxd07ueg6iND526oG1lT7vtM=; b=L0JmTKCKcS9Pm49/4dL+TphgjHN+VnKHhpNtKopi9eubrWXtWiQ13YZ9FvGgGYVk98 da0cR+TvckigWC9ZbELLhjiFnXBxrr6hImOrd+/6yR9bAIPQg/Q3dLTnOMzwLQv5toAS gdr85/z0B8t3pO+532HGFkk6DAuqqeZHrnujg= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1706191982; bh=2GKDcVy4qEfl0MBhRgumxd07ueg6iND526oG1lT7vtM=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=LSBSF40RRhEoGFhaLzUnTc6rIJ80Wf68PPmcF3BMKLBUoOMHG2KDoQl+zD3MXD4TB xMpC3qVuFcHAtABuXXc5W7rBw2fRwh1hIR+SvqgrPkrXduUmfWG4oXceF3sqxdcn8r t+kXujNutWXcFPO+S72UmBw7MlYbfsGPWLzs9rAlkyx10MaNIy2qr6cu4RJNi1jW7O TshqHMEq/eQJh6DocYl2MEoc1sI4rx1tLTzrPLmyjNGgjBo1z7f6n9F32Q36Y/h1Mu J6XXOQ1tvlbFTWN7Di6HrbEX7lt6WQbXh6tAAyzNwEBAdHNGJjmP9fb26j6gWpw63H oHkcWCjzFcu9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706191982; x=1706796782; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=2GKDcVy4qEfl0MBhRgumxd07ueg6iND526oG1lT7vtM=; b=RPkRWP4E0fG47AvBmDcZeK5HaympYX9o4mhubxyOlQ0TJSW58myBikUwWCnw/ToooQ Bgm08mQNNp/Ay8gVkyZDV9PF4Im09IUbTCP9qRZzeES+ry2cqYovZVJnRWRyrf/pwpYL uQzTZUtwoaYfwhCdmwq78hGejtCvVLHSJ+Hl5o+PWVFlEo2sy77owKLmZ6EBbr2NKPs1 GF+h06f/Vz7V/PxPhzBS9PRCQrUZ3DMnhJmH9iRAoU82JdUDJ6kuqLzp68ZUxvBoBwnC Yv9PbWRXsBxdO+9ymDN7X11XgdabJRtJIyCPZeSUkJdfu1lT1+Jn3DBT1wrvX6AgLkED tJ1g== X-Gm-Message-State: AOJu0YxtS/k4nuSv4IkJhE9H79VcUofDqRpV75W2mOyiUQZ+0o7SAAWD 99VIHAWuF5MQb0CF1ppiYWkxdC53jnhU/vZNxDjTiQqXBANmjWPvm40VAagZbJd5J+gKsg7u3LJ 9Q2UlRLtSLdHuEiIRlO3C1epu1zLVeem/6R40wm65N5+aLIXsulkLANAggQNW8g2tDiJp+h9AmG Jx8PUZ0lm6g5abZ/Oy1qc/wDBa3A== X-Received: by 2002:a17:907:a808:b0:a31:7ce5:d44b with SMTP id vo8-20020a170907a80800b00a317ce5d44bmr676049ejc.71.1706191982154; Thu, 25 Jan 2024 06:13:02 -0800 (PST) X-Google-Smtp-Source: AGHT+IFBZNWwh70adSPgDCwLQKR6lWGKiRLZeqFtwOwe7kavv+VNnTHOfN9wbeLjxB0BNwOsSzn6zMCh8jQjMhi69I0= X-Received: by 2002:a17:907:a808:b0:a31:7ce5:d44b with SMTP id vo8-20020a170907a80800b00a317ce5d44bmr676038ejc.71.1706191981837; Thu, 25 Jan 2024 06:13:01 -0800 (PST) MIME-Version: 1.0 References: <ierle8nye6u.fsf@HIDDEN> <797f3211-068f-4b7f-bb34-f3c9ee12241b@HIDDEN> <CAO=BR8O9zkOhuhc+3tWdaSW_B3LSgxfb=q_ywKZJn5ypyMSqnw@HIDDEN> In-Reply-To: <CAO=BR8O9zkOhuhc+3tWdaSW_B3LSgxfb=q_ywKZJn5ypyMSqnw@HIDDEN> From: Spencer Baugh <sbaugh@HIDDEN> Date: Thu, 25 Jan 2024 09:12:50 -0500 Message-ID: <CAO=BR8MgGZzvou4jvosF78tQuuysiwVnTNnJEGKLxe=NqjbAVg@HIDDEN> Subject: Re: bug#68546: 29.1.90; end-of-file has incorrect data when signaled within a load To: Dmitry Gutov <dmitry@HIDDEN> Content-Type: multipart/alternative; boundary="000000000000ff0fb6060fc5c6ea" X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 68546 Cc: 68546 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.3 (/) --000000000000ff0fb6060fc5c6ea Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jan 25, 2024 at 9:05=E2=80=AFAM Spencer Baugh <sbaugh@HIDDEN= m> wrote: > On Wed, Jan 17, 2024 at 3:55=E2=80=AFPM Dmitry Gutov <dmitry@HIDDEN> w= rote: > >> On 17/01/2024 21:04, Spencer Baugh wrote: >> > As one particular example of the confusing current behavior, a user ha= d >> > corrupted their ~/.emacs.d/projects so that reading it failed. Also, >> > they had a call to (project-forget-zombie-projects) in their init.el. >> > In combination, this meant Emacs startup errored with: >> > >> > End of file during parsing:/home/user/.emacs.d/init.el >> > >> > even though there was no syntax error in init.el at all. >> >> Would something like this help with this particular sub-problem? >> >> diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el >> index a6f14a0865c..196a82757b2 100644 >> --- a/lisp/progmodes/project.el >> +++ b/lisp/progmodes/project.el >> @@ -1694,7 +1694,9 @@ project--read-project-list >> (let ((name (car elem))) >> (list (if (file-remote-p name) name >> (abbreviate-file-name name))))) >> - (read (current-buffer)))))) >> + (condition-case nil >> + (read (current-buffer)) >> + (end-of-file (warn "Failed to read the projects list >> file"))))))) >> (unless (seq-every-p >> (lambda (elt) (stringp (car-safe elt))) >> project--list) >> >> > Yes, I think that would be great. Especially because this allows startup > to continue. If it's okay with you too, I think it's reasonable to push. > > This de-facto resets the contents of the projects list file (since the > corrupted version will get saved over), but I think that's fine - it's n= ot > especially hard information to rebuild, and if it's corrupt anyway then > it's probably already at least partially lost (in my case, a user had an > empty projects file for some reason, not sure why). Oh and I guess we > already reset the contents if it's in the wrong format. So yeah, this > seems great. > Ah, I think the cause (in at least one case) is that the user ran out of disk space, and so the write-region call in project--write-project-list failed when writing, which happens after truncating the existing file. I guess there should be some atomic version of write-region which writes to a temp file and renames it over the original. --000000000000ff0fb6060fc5c6ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr">On Thu, Jan 25, 2024 at 9:05=E2=80=AFAM S= pencer Baugh <<a href=3D"mailto:sbaugh@HIDDEN">sbaugh@janestreet= .com</a>> wrote:<br></div><div class=3D"gmail_quote"><blockquote class= =3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg= b(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"></div><d= iv class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Jan = 17, 2024 at 3:55=E2=80=AFPM Dmitry Gutov <<a href=3D"mailto:dmitry@gutov= .dev" target=3D"_blank">dmitry@HIDDEN</a>> wrote:<br></div><blockquot= e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s= olid rgb(204,204,204);padding-left:1ex">On 17/01/2024 21:04, Spencer Baugh = wrote:<br> > As one particular example of the confusing current behavior, a user ha= d<br> > corrupted their ~/.emacs.d/projects so that reading it failed.=C2=A0 A= lso,<br> > they had a call to (project-forget-zombie-projects) in their init.el.<= br> > In combination, this meant Emacs startup errored with:<br> > <br> > End of file during parsing:/home/user/.emacs.d/init.el<br> > <br> > even though there was no syntax error in init.el at all.<br> <br> Would something like this help with this particular sub-problem?<br> <br> diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el<br> index a6f14a0865c..196a82757b2 100644<br> --- a/lisp/progmodes/project.el<br> +++ b/lisp/progmodes/project.el<br> @@ -1694,7 +1694,9 @@ project--read-project-list<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(let (= (name (car elem)))<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0(list (if (file-remote-p name) name<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(abbreviate-file-name name)))))<br> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(read (current-buff= er))))))<br> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(condition-case nil= <br> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(read= (current-buffer))<br> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(end-of-file= (warn "Failed to read the projects list <br> file")))))))<br> =C2=A0 =C2=A0 =C2=A0 (unless (seq-every-p<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(lambda (elt) (strin= gp (car-safe elt)))<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0project--list)<br> <br></blockquote><div><br></div><div>Yes, I think that would be great.=C2= =A0 Especially because this allows startup to continue.=C2=A0 If it's o= kay with you too, I think it's reasonable to push.</div><div><br></div>= <div>This de-facto resets the contents of the projects list file (since the= corrupted version will get saved over), but I think=C2=A0that's fine -= =C2=A0 it's not especially hard information to rebuild, and if it's= corrupt anyway then it's probably already at least partially lost (in = my case, a user had an empty projects file for some reason, not sure why).= =C2=A0 Oh and I guess we already reset the contents if it's in the wron= g format.=C2=A0 So yeah, this seems great.</div></div></div></blockquote><d= iv><br></div><div>Ah, I think the cause (in at least one case) is that the = user ran out of disk space, and so the write-region call in=C2=A0project--w= rite-project-list failed when writing, which happens after truncating the e= xisting file.=C2=A0 I guess there should be some atomic version of write-re= gion which writes to a temp file and renames it over the original.</div></d= iv></div> --000000000000ff0fb6060fc5c6ea--
bug-gnu-emacs@HIDDEN:bug#68546; Package emacs.
Full text available.Received: (at 68546) by debbugs.gnu.org; 25 Jan 2024 14:05:46 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jan 25 09:05:46 2024 Received: from localhost ([127.0.0.1]:47668 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rT0MT-0000xi-TF for submit <at> debbugs.gnu.org; Thu, 25 Jan 2024 09:05:46 -0500 Received: from mxout1.mail.janestreet.com ([38.105.200.78]:41481) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <sbaugh@HIDDEN>) id 1rT0MQ-0000xU-Vq for 68546 <at> debbugs.gnu.org; Thu, 25 Jan 2024 09:05:43 -0500 Received: from mail-ej1-f70.google.com ([209.85.218.70]) by mxgoog2.mail.janestreet.com with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128) (Exim 4.97.1) id 1rT0MG-0000000BMWW-2uLw for 68546 <at> debbugs.gnu.org; Thu, 25 Jan 2024 09:05:31 -0500 Received: by mail-ej1-f70.google.com with SMTP id a640c23a62f3a-a330b31c1fcso9804066b.2 for <68546 <at> debbugs.gnu.org>; Thu, 25 Jan 2024 06:05:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=google; t=1706191530; x=1706796330; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=0NrVEeeRZWfe3TQDNYncKn1J9oYvgeAkeZy/V/kNSTU=; b=sF9xRbuRtpXmSiYOrozNVMs7vqAFy4btoSWRNmuJOAE8xvdOgKZNaR6OgzvlIh8jwo hdbHYcwK5KTJTKoSnW4o0dcous6pdTpNvxMyuE0lZi3Ri30Jktrrhjdp75zPsfbeCST0 lli68che50LUFD0WpH/1+sf7V6rdyzRy1uNcY= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1706191531; bh=0NrVEeeRZWfe3TQDNYncKn1J9oYvgeAkeZy/V/kNSTU=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=V+QeY/sI6BW70TjxfIlP96i3qmXLe8HpSRyncBbGtlodac8NT3+7xNIWzFsxxOq3i d7uObhEik8HWBTqTW5011lkVfJsYYlpN4XqTUOLMt6+ghwAOr4fdIOGmDGGQsBgvGA IWpyPhBDX8Dvh6VjxCh03uVLUeMw2U/ZD4k4ZNXnY9pLZtsqrRllclT4rY3xCr1myT AcfvQaA4NN2gzA8CObazp82GGuXtwfa0jmZjNxYRUaAS759nhFv40HwpNJIK6d+EDW bVJlUe+ZPipPqzatHGAdOsIuzEqcXin0jkD7cgyMUgPi4r6v18bioQrQVqCze4597G mXOqC/YW5FNTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706191530; x=1706796330; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=0NrVEeeRZWfe3TQDNYncKn1J9oYvgeAkeZy/V/kNSTU=; b=no05DsOn2CvkeHEuBHjoqATgUJZROBZNwvgPRWKzdd3Mi+GkCh7/LgX1C9du8kBOY0 9V635yyVQt/37133fNvfr7C7RMUhE02jVxnNQECI25VPFZjOITQK+QSJrUjBLTo58Ux5 FYzpfejZ86YEmTH3i7M8PVQ4nm09x3hmKXXTn+/daD1oqZR9JBvR4EYmGE8r3+A2ahkG j8mQ0kzeFi3OF/iNUhexcgfOV0iHRDsK/2Evqo67jwkYUHHJEHyu+fUDTmsLF0qnduft x8FWATiAecEfO9SXjzZGtGOvgYdOe6vQzYcb/67D4IvadnxWUcfq4Y6n6XvI8Eu+gwhL ddAg== X-Gm-Message-State: AOJu0YxiZHtX4OVQ/QFCzv6EBW+TpFa7qo1ziya4h5x1Ivk6JmH4f7Tl oY3Vy2g+Xvd15S78xra8LeZPM/TYF4+I+aw+2tFLlcG8sIQ0ji6SnhbkFz0ApBrZP40j4JpT5zM 0Odipc09HYqCR0No4gjiwag9NhpTFJ1mIVoDb8GPlBXivYemf7AY1OEU7XGTEPFXARwS7YG9NUr mXEKwPyxhMyyy+fWQZaDv+jYVib2mlcBBTHQ== X-Received: by 2002:a17:907:6e92:b0:a31:4108:9707 with SMTP id sh18-20020a1709076e9200b00a3141089707mr644824ejc.13.1706191530115; Thu, 25 Jan 2024 06:05:30 -0800 (PST) X-Google-Smtp-Source: AGHT+IHqtE1Arp3jQsDZvuQS0kr+MdzevzAHINBc5gXneM1RZlk+SOUDbHQHAzYURe0qav1icrgWBt5iX+/NNHKAPOk= X-Received: by 2002:a17:907:6e92:b0:a31:4108:9707 with SMTP id sh18-20020a1709076e9200b00a3141089707mr644814ejc.13.1706191529769; Thu, 25 Jan 2024 06:05:29 -0800 (PST) MIME-Version: 1.0 References: <ierle8nye6u.fsf@HIDDEN> <797f3211-068f-4b7f-bb34-f3c9ee12241b@HIDDEN> In-Reply-To: <797f3211-068f-4b7f-bb34-f3c9ee12241b@HIDDEN> From: Spencer Baugh <sbaugh@HIDDEN> Date: Thu, 25 Jan 2024 09:05:19 -0500 Message-ID: <CAO=BR8O9zkOhuhc+3tWdaSW_B3LSgxfb=q_ywKZJn5ypyMSqnw@HIDDEN> Subject: Re: bug#68546: 29.1.90; end-of-file has incorrect data when signaled within a load To: Dmitry Gutov <dmitry@HIDDEN> Content-Type: multipart/alternative; boundary="0000000000000d10a2060fc5ac8d" X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 68546 Cc: 68546 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.3 (/) --0000000000000d10a2060fc5ac8d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jan 17, 2024 at 3:55=E2=80=AFPM Dmitry Gutov <dmitry@HIDDEN> wro= te: > On 17/01/2024 21:04, Spencer Baugh wrote: > > As one particular example of the confusing current behavior, a user had > > corrupted their ~/.emacs.d/projects so that reading it failed. Also, > > they had a call to (project-forget-zombie-projects) in their init.el. > > In combination, this meant Emacs startup errored with: > > > > End of file during parsing:/home/user/.emacs.d/init.el > > > > even though there was no syntax error in init.el at all. > > Would something like this help with this particular sub-problem? > > diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el > index a6f14a0865c..196a82757b2 100644 > --- a/lisp/progmodes/project.el > +++ b/lisp/progmodes/project.el > @@ -1694,7 +1694,9 @@ project--read-project-list > (let ((name (car elem))) > (list (if (file-remote-p name) name > (abbreviate-file-name name))))) > - (read (current-buffer)))))) > + (condition-case nil > + (read (current-buffer)) > + (end-of-file (warn "Failed to read the projects list > file"))))))) > (unless (seq-every-p > (lambda (elt) (stringp (car-safe elt))) > project--list) > > Yes, I think that would be great. Especially because this allows startup to continue. If it's okay with you too, I think it's reasonable to push. This de-facto resets the contents of the projects list file (since the corrupted version will get saved over), but I think that's fine - it's not especially hard information to rebuild, and if it's corrupt anyway then it's probably already at least partially lost (in my case, a user had an empty projects file for some reason, not sure why). Oh and I guess we already reset the contents if it's in the wrong format. So yeah, this seems great. --0000000000000d10a2060fc5ac8d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"></div><div class=3D"gmail_quote"><div dir= =3D"ltr" class=3D"gmail_attr">On Wed, Jan 17, 2024 at 3:55=E2=80=AFPM Dmitr= y Gutov <<a href=3D"mailto:dmitry@HIDDEN">dmitry@HIDDEN</a>> wr= ote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px= 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 17/01/20= 24 21:04, Spencer Baugh wrote:<br> > As one particular example of the confusing current behavior, a user ha= d<br> > corrupted their ~/.emacs.d/projects so that reading it failed.=C2=A0 A= lso,<br> > they had a call to (project-forget-zombie-projects) in their init.el.<= br> > In combination, this meant Emacs startup errored with:<br> > <br> > End of file during parsing:/home/user/.emacs.d/init.el<br> > <br> > even though there was no syntax error in init.el at all.<br> <br> Would something like this help with this particular sub-problem?<br> <br> diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el<br> index a6f14a0865c..196a82757b2 100644<br> --- a/lisp/progmodes/project.el<br> +++ b/lisp/progmodes/project.el<br> @@ -1694,7 +1694,9 @@ project--read-project-list<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(let (= (name (car elem)))<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0(list (if (file-remote-p name) name<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(abbreviate-file-name name)))))<br> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(read (current-buff= er))))))<br> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(condition-case nil= <br> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(read= (current-buffer))<br> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(end-of-file= (warn "Failed to read the projects list <br> file")))))))<br> =C2=A0 =C2=A0 =C2=A0 (unless (seq-every-p<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(lambda (elt) (strin= gp (car-safe elt)))<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0project--list)<br> <br></blockquote><div><br></div><div>Yes, I think that would be great.=C2= =A0 Especially because this allows startup to continue.=C2=A0 If it's o= kay with you too, I think it's reasonable to push.</div><div><br></div>= <div>This de-facto resets the contents of the projects list file (since the= corrupted version will get saved over), but I think=C2=A0that's fine -= =C2=A0 it's not especially hard information to rebuild, and if it's= corrupt anyway then it's probably already at least partially lost (in = my case, a user had an empty projects file for some reason, not sure why).= =C2=A0 Oh and I guess we already reset the contents if it's in the wron= g format.=C2=A0 So yeah, this seems great.</div></div></div> --0000000000000d10a2060fc5ac8d--
bug-gnu-emacs@HIDDEN:bug#68546; Package emacs.
Full text available.
Received: (at 68546) by debbugs.gnu.org; 17 Jan 2024 20:55:56 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jan 17 15:55:56 2024
Received: from localhost ([127.0.0.1]:53650 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rQCx2-0005se-8D
for submit <at> debbugs.gnu.org; Wed, 17 Jan 2024 15:55:56 -0500
Received: from wout3-smtp.messagingengine.com ([64.147.123.19]:58047)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <dmitry@HIDDEN>) id 1rQCwz-0005sP-80
for 68546 <at> debbugs.gnu.org; Wed, 17 Jan 2024 15:55:54 -0500
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45])
by mailout.west.internal (Postfix) with ESMTP id 08C133200B50;
Wed, 17 Jan 2024 15:55:45 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162])
by compute5.internal (MEProxy); Wed, 17 Jan 2024 15:55:46 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc
:content-transfer-encoding:content-type:content-type:date:date
:from:from:in-reply-to:in-reply-to:message-id:mime-version
:references:reply-to:subject:subject:to:to; s=fm1; t=1705524945;
x=1705611345; bh=0YPFMIz/Hgd2i3fMako2OnA8+hGU51lSdd2WWA5XGwo=; b=
G+SUU92qKDDWDwRhY8iXR5dNX7ccG14yRsfbhDaWeEjPQkjXxUSNR3fL2N1Onv/t
uQfiR6LtIE7Aml4JHrbiF4k9hIPxNJrDDWONSRkL/S2oDqYHXdpVyPoGqsgZr5Gq
vXJuZZTqWSjBL6IlRC8SjKrdnH1F+CloXiTtGnc5ND82iL8gpG2jqtO3Lq0XCPhI
8Queap/xt7fOW4PNubtk3qrhIQdYcRjpXFnz2rasAICOf2K0z1n6sah1Wi5f1Skh
s/DoJ7uGjR6RmDJ1NMUHeanE7Fkmc+tx1lCSPfcYpHTquVVpf9lmOBeeVhzSFfvk
k9/HlRJQChvtJLYkiiPVVw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=cc:content-transfer-encoding:content-type
:content-type:date:date:feedback-id:feedback-id:from:from
:in-reply-to:in-reply-to:message-id:mime-version:references
:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy
:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1705524945; x=
1705611345; bh=0YPFMIz/Hgd2i3fMako2OnA8+hGU51lSdd2WWA5XGwo=; b=U
vCZVciO7z1xCBWCMqnry30yjK727ancI35VJIoATR4fEUnyR2kJ/rbvUDap2C0nn
JTIf83MYl47AC+uyDBh7ZWbE9k/9/qQk+V/4nBrBhVdMvFg/zxPW7hu3n64RlEZ3
+wFg9hmKrBd5lFEe1pLdwpYWWuyA+Vf8oXfc/yeevxlrvqcrOo7qnKEtZ7ebsDuw
lGNVbJLQk+tAqExFHko0TJ6FWwLXmEQRxbBBH1hJedKKKZ0tEnTpFLnR4LDERD/R
DtBiuC4bjAJC//p95sW6DYUTOmz+LHE61IdW4Cs6vvg659qlXQomIjorXJEp5ftg
WgRBAMRICuAM3McXUHCHQ==
X-ME-Sender: <xms:0T6oZXabPGEyQwRKWjjixUiPQNsOm-ktR84md4uj9eIkcrUB6jU5oA>
<xme:0T6oZWZROMeB5oHGSrlnjXUFveVzMEn_Pz32-nLrb1FlTo3bAWvgAm-TmeOn63tq1
d17-5S1O-FptdsNs8g>
X-ME-Received: <xmr:0T6oZZ-khOE9wu2IsLijSEOieSlUGLxjJP9j7GcAYiE6j0EeBQV13igZJxf5MkkvGBGytg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdejhedgudefkecutefuodetggdotefrod
ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh
necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd
enucfjughrpefkffggfgfuvfhfhfgjtgfgsehtjeertddtvdejnecuhfhrohhmpeffmhhi
thhrhicuifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrth
htvghrnhepgfekteeggedtleevgfehledtheetffegteeiheehueegudduueehudefgfei
feegnecuffhomhgrihhnpegvlhdrihhnnecuvehluhhsthgvrhfuihiivgeptdenucfrrg
hrrghmpehmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghv
X-ME-Proxy: <xmx:0T6oZdpd2Bp3985vLszG9UhxAY6RRPDctXRvokyRNob9I-vCRBjqfA>
<xmx:0T6oZSqWrZ8-Xm1x-NSPIIs_uBSOkGPiNpc2duwkyxj4UrntLy24TA>
<xmx:0T6oZTRIcU0oA788TGYHpSTUmK0fIDTKEJ_BWZ8VsI7grN8DvBFLyw>
<xmx:0T6oZZQWoCioSuSj41ZAs5vit__vrVyjpOWWNJ4cHjhQipv8N1m9Fw>
Feedback-ID: i0e71465a:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed,
17 Jan 2024 15:55:44 -0500 (EST)
Message-ID: <797f3211-068f-4b7f-bb34-f3c9ee12241b@HIDDEN>
Date: Wed, 17 Jan 2024 22:55:41 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: bug#68546: 29.1.90; end-of-file has incorrect data when signaled
within a load
Content-Language: en-US
To: Spencer Baugh <sbaugh@HIDDEN>, 68546 <at> debbugs.gnu.org
References: <ierle8nye6u.fsf@HIDDEN>
From: Dmitry Gutov <dmitry@HIDDEN>
In-Reply-To: <ierle8nye6u.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 68546
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
On 17/01/2024 21:04, Spencer Baugh wrote:
> As one particular example of the confusing current behavior, a user had
> corrupted their ~/.emacs.d/projects so that reading it failed. Also,
> they had a call to (project-forget-zombie-projects) in their init.el.
> In combination, this meant Emacs startup errored with:
>
> End of file during parsing:/home/user/.emacs.d/init.el
>
> even though there was no syntax error in init.el at all.
Would something like this help with this particular sub-problem?
diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
index a6f14a0865c..196a82757b2 100644
--- a/lisp/progmodes/project.el
+++ b/lisp/progmodes/project.el
@@ -1694,7 +1694,9 @@ project--read-project-list
(let ((name (car elem)))
(list (if (file-remote-p name) name
(abbreviate-file-name name)))))
- (read (current-buffer))))))
+ (condition-case nil
+ (read (current-buffer))
+ (end-of-file (warn "Failed to read the projects list
file")))))))
(unless (seq-every-p
(lambda (elt) (stringp (car-safe elt)))
project--list)
bug-gnu-emacs@HIDDEN:bug#68546; Package emacs.
Full text available.Received: (at submit) by debbugs.gnu.org; 17 Jan 2024 19:04:24 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jan 17 14:04:24 2024 Received: from localhost ([127.0.0.1]:53497 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rQBD5-0000n9-Ov for submit <at> debbugs.gnu.org; Wed, 17 Jan 2024 14:04:24 -0500 Received: from lists.gnu.org ([2001:470:142::17]:50056) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <sbaugh@HIDDEN>) id 1rQBD3-0000mt-1Y for submit <at> debbugs.gnu.org; Wed, 17 Jan 2024 14:04:21 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <sbaugh@HIDDEN>) id 1rQBCw-0001r7-I5 for bug-gnu-emacs@HIDDEN; Wed, 17 Jan 2024 14:04:14 -0500 Received: from mxout5.mail.janestreet.com ([64.215.233.18]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <sbaugh@HIDDEN>) id 1rQBCu-0005jD-Cj for bug-gnu-emacs@HIDDEN; Wed, 17 Jan 2024 14:04:14 -0500 From: Spencer Baugh <sbaugh@HIDDEN> To: bug-gnu-emacs@HIDDEN Subject: 29.1.90; end-of-file has incorrect data when signaled within a load Date: Wed, 17 Jan 2024 14:04:09 -0500 Message-ID: <ierle8nye6u.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1705518250; bh=WnrGOgSqcpBWzDGKY5Vt3Ews91Kvukc5Bgo1+tjFN9s=; h=From:To:Cc:Subject:Date; b=rKdvkI/7+5r+fUvcCNEjbMem3pj5ie6U//jarlStPlwb0QxvC+rOJEVNHU24/LZAF 6hPR1Qx2dJap8Je7WcKR7rKc0vQ16NoDBNUZbLinQsxSv+mctzDVrQIImrBAoQ8/BO DQi3RQPXKsMQZnjhGly2jQHIOq5cV4CMtQVBYj8mW6PGrsrNM751lAzYpq4iBRobDJ aJ1Pv2CpNEjYQGXpcB4KE0m7ITkg6I9XM+NkhfTTez5b9x4drveoEwWQf6TDPNSAn7 ikwq8LRJBI2aS/NBo6DsK8esLSCgo5qv7QmfvtJDuPj874pHJq9mqoz7IS82ylWrAm 150MqUFmmGBXg== Received-SPF: pass client-ip=64.215.233.18; envelope-from=sbaugh@HIDDEN; helo=mxout5.mail.janestreet.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.9 (/) X-Debbugs-Envelope-To: submit Cc: dmitry@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.1 (/) The end-of-file error signaled by read has incorrect data if it's signaled during a load, by a read unrelated to that load. 1. Create a file "~/read-empty.el" containing: (read "") 2. (load "~/read-empty.el") 3. Observe the error message: End of file during parsing: /home/sbaugh/read-empty.el This error message suggests that there's a syntax error in read-empty.el, when in fact the syntax error is in something else entirely. This is quite confusing. This happens because end_of_file_error uses load-true-file-name if it's non-nil, even if the actual read call is unrelated. One possible fix: a new variable read-file-name could be introduced, and end_of_file_error could use that instead of load-true-file-name, and load can just bind read-file-name around read. As one particular example of the confusing current behavior, a user had corrupted their ~/.emacs.d/projects so that reading it failed. Also, they had a call to (project-forget-zombie-projects) in their init.el. In combination, this meant Emacs startup errored with: End of file during parsing: /home/user/.emacs.d/init.el even though there was no syntax error in init.el at all. To resolve that, perhaps project--read-project-list could bind read-file-name to project-list-file, so we'd get an error message which properly mentions the project file instead. In GNU Emacs 29.1.90 (build 8, x86_64-pc-linux-gnu, X toolkit, cairo version 1.15.12, Xaw scroll bars) of 2024-01-04 built on igm-qws-u22796a Repository revision: 57fa5a53f74e489702825045832f52730c5d550f Repository branch: emacs-29 Windowing system distributor 'The X.Org Foundation', version 11.0.12011000 System Description: Rocky Linux 8.9 (Green Obsidian) Configured using: 'configure 'CFLAGS=-O0 -g3' --with-gif=ifavailable --with-x-toolkit=lucid' Configured features: CAIRO DBUS FREETYPE GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON LIBSELINUX LIBSYSTEMD LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS X11 XDBE XIM XINPUT2 XPM LUCID ZLIB Important settings: value of $LANG: en_US.UTF-8 locale-coding-system: utf-8-unix Major mode: Lisp Interaction Minor modes in effect: tooltip-mode: t global-eldoc-mode: t eldoc-mode: t show-paren-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t line-number-mode: t indent-tabs-mode: t transient-mark-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t Load-path shadows: None found. Features: (shadow sort mail-extr emacsbug message mailcap yank-media puny dired dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068 epg-config gnus-util text-property-search time-date subr-x mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils rmc iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors frame minibuffer nadvice seq simple cl-generic indonesian philippine cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget keymap hashtable-print-readable backquote threads dbusbind inotify dynamic-setting system-font-setting font-render-setting cairo x-toolkit xinput2 x multi-tty make-network-process emacs) Memory information: ((conses 16 63231 9564) (symbols 48 9475 0) (strings 32 22767 1134) (string-bytes 1 677438) (vectors 16 9316) (vector-slots 8 148900 13842) (floats 8 34 25) (intervals 56 241 0) (buffers 976 10))
Spencer Baugh <sbaugh@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#68546; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.