GNU logs - #68546, boring messages

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#68546: 29.1.90; end-of-file has incorrect data when signaled within a load
Resent-From: Spencer Baugh <sbaugh@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 17 Jan 2024 19:05:02 +0000
Resent-Message-ID: <handler.68546.B.17055182643051 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 68546 <at> debbugs.gnu.org
Cc: dmitry@HIDDEN
From: Spencer Baugh <sbaugh@HIDDEN>
Date: Wed, 17 Jan 2024 14:04:09 -0500
Message-ID: <ierle8nye6u.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
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-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))

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Spencer Baugh <sbaugh@HIDDEN>
Subject: bug#68546: Acknowledgement (29.1.90; end-of-file has incorrect
 data when signaled within a load)
Message-ID: <handler.68546.B.17055182643051.ack <at> debbugs.gnu.org>
References: <ierle8nye6u.fsf@HIDDEN>
X-Gnu-PR-Message: ack 68546
X-Gnu-PR-Package: emacs
Reply-To: 68546 <at> debbugs.gnu.org
Date: Wed, 17 Jan 2024 19:05:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 68546 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
68546: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D68546
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#68546: 29.1.90; end-of-file has incorrect data when signaled within a load
Resent-From: Dmitry Gutov <dmitry@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 17 Jan 2024 20:56:02 +0000
Resent-Message-ID: <handler.68546.B68546.170552495622613 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Spencer Baugh <sbaugh@HIDDEN>, 68546 <at> debbugs.gnu.org
Feedback-ID: i0e71465a:Fastmail
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
Content-Language: en-US
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
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

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)

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#68546: 29.1.90; end-of-file has incorrect data when signaled within a load
Resent-From: Spencer Baugh <sbaugh@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 25 Jan 2024 14:06:01 +0000
Resent-Message-ID: <handler.68546.B68546.17061915463707 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Dmitry Gutov <dmitry@HIDDEN>
Cc: 68546 <at> debbugs.gnu.org
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>
Content-Type: multipart/alternative; boundary="0000000000000d10a2060fc5ac8d"
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

--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 &lt;<a href=3D"mailto:dmitry@HIDDEN">dmitry@HIDDEN</a>&gt; 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>
&gt; As one particular example of the confusing current behavior, a user ha=
d<br>
&gt; corrupted their ~/.emacs.d/projects so that reading it failed.=C2=A0 A=
lso,<br>
&gt; they had a call to (project-forget-zombie-projects) in their init.el.<=
br>
&gt; In combination, this meant Emacs startup errored with:<br>
&gt; <br>
&gt; End of file during parsing:/home/user/.emacs.d/init.el<br>
&gt; <br>
&gt; 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 &quot;Failed to read the projects list <br>
file&quot;)))))))<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&#39;s o=
kay with you too, I think it&#39;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&#39;s fine -=
=C2=A0 it&#39;s not especially hard information to rebuild, and if it&#39;s=
 corrupt anyway then it&#39;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&#39;s in the wron=
g format.=C2=A0 So yeah, this seems great.</div></div></div>

--0000000000000d10a2060fc5ac8d--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#68546: 29.1.90; end-of-file has incorrect data when signaled within a load
Resent-From: Spencer Baugh <sbaugh@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 25 Jan 2024 14:14:02 +0000
Resent-Message-ID: <handler.68546.B68546.17061919964404 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 68546
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Dmitry Gutov <dmitry@HIDDEN>
Cc: 68546 <at> debbugs.gnu.org
Received: via spool by 68546-submit <at> debbugs.gnu.org id=B68546.17061919964404
          (code B ref 68546); Thu, 25 Jan 2024 14:14:02 +0000
Received: (at 68546) by debbugs.gnu.org; 25 Jan 2024 14:13:16 +0000
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>
Content-Type: multipart/alternative; boundary="000000000000ff0fb6060fc5c6ea"
X-Spam-Score: 0.7 (/)
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 &lt;<a href=3D"mailto:sbaugh@HIDDEN">sbaugh@janestreet=
.com</a>&gt; 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 &lt;<a href=3D"mailto:dmitry@gutov=
.dev" target=3D"_blank">dmitry@HIDDEN</a>&gt; 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>
&gt; As one particular example of the confusing current behavior, a user ha=
d<br>
&gt; corrupted their ~/.emacs.d/projects so that reading it failed.=C2=A0 A=
lso,<br>
&gt; they had a call to (project-forget-zombie-projects) in their init.el.<=
br>
&gt; In combination, this meant Emacs startup errored with:<br>
&gt; <br>
&gt; End of file during parsing:/home/user/.emacs.d/init.el<br>
&gt; <br>
&gt; 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 &quot;Failed to read the projects list <br>
file&quot;)))))))<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&#39;s o=
kay with you too, I think it&#39;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&#39;s fine -=
=C2=A0 it&#39;s not especially hard information to rebuild, and if it&#39;s=
 corrupt anyway then it&#39;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&#39;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--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#68546: 29.1.90; end-of-file has incorrect data when signaled within a load
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 25 Jan 2024 14:30:02 +0000
Resent-Message-ID: <handler.68546.B68546.17061929865908 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 68546
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Spencer Baugh <sbaugh@HIDDEN>
Cc: dmitry@HIDDEN, 68546 <at> debbugs.gnu.org
Received: via spool by 68546-submit <at> debbugs.gnu.org id=B68546.17061929865908
          (code B ref 68546); Thu, 25 Jan 2024 14:30:02 +0000
Received: (at 68546) by debbugs.gnu.org; 25 Jan 2024 14:29:46 +0000
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>
In-Reply-To: <CAO=BR8O9zkOhuhc+3tWdaSW_B3LSgxfb=q_ywKZJn5ypyMSqnw@HIDDEN>
 (message from Spencer Baugh on Thu, 25 Jan 2024 09:05:19 -0500)
References: <ierle8nye6u.fsf@HIDDEN>
 <797f3211-068f-4b7f-bb34-f3c9ee12241b@HIDDEN>
 <CAO=BR8O9zkOhuhc+3tWdaSW_B3LSgxfb=q_ywKZJn5ypyMSqnw@HIDDEN>
X-Spam-Score: -2.3 (--)
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

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#68546: 29.1.90; end-of-file has incorrect data when signaled within a load
Resent-From: Dmitry Gutov <dmitry@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 26 Jan 2024 00:46:02 +0000
Resent-Message-ID: <handler.68546.B68546.17062299436482 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 68546
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>, Spencer Baugh <sbaugh@HIDDEN>
Cc: 68546 <at> debbugs.gnu.org
Received: via spool by 68546-submit <at> debbugs.gnu.org id=B68546.17062299436482
          (code B ref 68546); Fri, 26 Jan 2024 00:46:02 +0000
Received: (at 68546) by debbugs.gnu.org; 26 Jan 2024 00:45:43 +0000
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
Content-Language: en-US
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-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.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#68546: 29.1.90; end-of-file has incorrect data when signaled within a load
Resent-From: Dmitry Gutov <dmitry@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 26 Jan 2024 00:55:01 +0000
Resent-Message-ID: <handler.68546.B68546.17062304807771 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 68546
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Spencer Baugh <sbaugh@HIDDEN>
Cc: 68546 <at> debbugs.gnu.org
Received: via spool by 68546-submit <at> debbugs.gnu.org id=B68546.17062304807771
          (code B ref 68546); Fri, 26 Jan 2024 00:55:01 +0000
Received: (at 68546) by debbugs.gnu.org; 26 Jan 2024 00:54:40 +0000
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
Content-Language: en-US
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-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.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#68546: 29.1.90; end-of-file has incorrect data when signaled within a load
Resent-From: Dmitry Gutov <dmitry@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 26 Jan 2024 00:57:01 +0000
Resent-Message-ID: <handler.68546.B68546.17062305717987 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 68546
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Spencer Baugh <sbaugh@HIDDEN>
Cc: 68546 <at> debbugs.gnu.org
Received: via spool by 68546-submit <at> debbugs.gnu.org id=B68546.17062305717987
          (code B ref 68546); Fri, 26 Jan 2024 00:57:01 +0000
Received: (at 68546) by debbugs.gnu.org; 26 Jan 2024 00:56:11 +0000
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
Content-Language: en-US
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-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.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#68546: 29.1.90; end-of-file has incorrect data when signaled within a load
Resent-From: Spencer Baugh <sbaugh@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 16 Feb 2024 21:57:02 +0000
Resent-Message-ID: <handler.68546.B68546.170812061512012 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 68546
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: 68546 <at> debbugs.gnu.org
Cc: dmitry@HIDDEN
Received: via spool by 68546-submit <at> debbugs.gnu.org id=B68546.170812061512012
          (code B ref 68546); Fri, 16 Feb 2024 21:57:02 +0000
Received: (at 68546) by debbugs.gnu.org; 16 Feb 2024 21:56:55 +0000
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>
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-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


--=-=-=--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#68546: 29.1.90; end-of-file has incorrect data when signaled within a load
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 17 Feb 2024 07:18:02 +0000
Resent-Message-ID: <handler.68546.B68546.170815426214070 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 68546
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Spencer Baugh <sbaugh@HIDDEN>, Stefan Monnier <monnier@HIDDEN>
Cc: dmitry@HIDDEN, 68546 <at> debbugs.gnu.org
Received: via spool by 68546-submit <at> debbugs.gnu.org id=B68546.170815426214070
          (code B ref 68546); Sat, 17 Feb 2024 07:18:02 +0000
Received: (at 68546) by debbugs.gnu.org; 17 Feb 2024 07:17:42 +0000
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>
In-Reply-To: <iery1bkysxh.fsf@HIDDEN> (message from Spencer Baugh on
 Fri, 16 Feb 2024 16:56:26 -0500)
References: <ierle8nye6u.fsf@HIDDEN>
 <iery1bkysxh.fsf@HIDDEN>
X-Spam-Score: -4.2 (----)
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.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#68546: 29.1.90; end-of-file has incorrect data when signaled within a load
Resent-From: Spencer Baugh <sbaugh@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 15 Oct 2024 19:17:01 +0000
Resent-Message-ID: <handler.68546.B68546.172901978717674 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 68546
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: dmitry@HIDDEN, Stefan Monnier <monnier@HIDDEN>, 68546 <at> debbugs.gnu.org
Received: via spool by 68546-submit <at> debbugs.gnu.org id=B68546.172901978717674
          (code B ref 68546); Tue, 15 Oct 2024 19:17:01 +0000
Received: (at 68546) by debbugs.gnu.org; 15 Oct 2024 19:16:27 +0000
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>
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-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


--=-=-=--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#68546: 29.1.90; end-of-file has incorrect data when signaled within a load
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 17 Oct 2024 17:58:02 +0000
Resent-Message-ID: <handler.68546.B68546.172918788115635 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 68546
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Spencer Baugh <sbaugh@HIDDEN>
Cc: dmitry@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, 68546 <at> debbugs.gnu.org
Received: via spool by 68546-submit <at> debbugs.gnu.org id=B68546.172918788115635
          (code B ref 68546); Thu, 17 Oct 2024 17:58:02 +0000
Received: (at 68546) by debbugs.gnu.org; 17 Oct 2024 17:58:01 +0000
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>
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-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

Last modified: Sun, 12 Jan 2025 05:45:02 UTC

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