GNU bug report logs - #63722
29.0.91; (elisp) Skip to end #@00 does not work

Previous Next

Package: emacs;

Reported by: richard newton <richardn26 <at> gmail.com>

Date: Thu, 25 May 2023 17:39:02 UTC

Severity: normal

Found in version 29.0.91

Done: Mattias Engdegård <mattiase <at> acm.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 63722 in the body.
You can then email your comments to 63722 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#63722; Package emacs. (Thu, 25 May 2023 17:39:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to richard newton <richardn26 <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Thu, 25 May 2023 17:39:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: richard newton <richardn26 <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.91; (elisp) Skip to end #@00 does not work
Date: Thu, 25 May 2023 16:19:42 +0200
[Message part 1 (text/plain, inline)]
With emacs 29.0.91 pretest, the "skip to end" syntax #@00 no longer seems
to work. For example, with the three lines below in a buffer (eval-buffer)
gives the error - End of file during parsing. With previous emacs versions
it did not complain.

(setq testStr "zz")
#@00
should be ignored

In GNU Emacs 29.0.91 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.37, cairo version 1.16.0) of 2023-05-18 built on n26-hp
Windowing system distributor 'The X.Org Foundation', version 11.0.12201009
System Description: Debian GNU/Linux 12 (bookworm)

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS
WEBP X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#63722; Package emacs. (Thu, 25 May 2023 18:45:02 GMT) Full text and rfc822 format available.

Message #8 received at 63722 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: richard newton <richardn26 <at> gmail.com>, Mattias Engdegård <mattiase <at> acm.org>
Cc: 63722 <at> debbugs.gnu.org
Subject: Re: bug#63722: 29.0.91; (elisp) Skip to end #@00 does not work
Date: Thu, 25 May 2023 21:44:28 +0300
> From: richard newton <richardn26 <at> gmail.com>
> Date: Thu, 25 May 2023 16:19:42 +0200
> 
> With emacs 29.0.91 pretest, the "skip to end" syntax #@00 no longer seems to work. For example,
> with the three lines below in a buffer (eval-buffer) gives the error - End of file during parsing. With
> previous emacs versions it did not complain.
> 
> (setq testStr "zz")
> #@00
> should be ignored

Thanks.

Mattias, this is due to commit b903507b36, which fixed bug#55676.  It
introduced a subtle change in the behavior of read0 in this case.

Does the below look like the correct way of fixing this regression?

diff --git a/src/lread.c b/src/lread.c
index 342d367..6ee2829 100644
--- a/src/lread.c
+++ b/src/lread.c
@@ -3400,8 +3400,9 @@ read_bool_vector (Lisp_Object readcharfun)
 }
 
 /* Skip (and optionally remember) a lazily-loaded string
-   preceded by "#@".  */
-static void
+   preceded by "#@".  Return non-zero if we skip to EOB,
+   otherwise zero.  */
+static bool
 skip_lazy_string (Lisp_Object readcharfun)
 {
   ptrdiff_t nskip = 0;
@@ -3429,7 +3430,7 @@ skip_lazy_string (Lisp_Object readcharfun)
 	{
 	  /* #@00 means "skip to end" */
 	  skip_dyn_eof (readcharfun);
-	  return;
+	  return true;
 	}
     }
 
@@ -3476,6 +3477,8 @@ skip_lazy_string (Lisp_Object readcharfun)
   else
     /* Skip that many bytes.  */
     skip_dyn_bytes (readcharfun, nskip);
+
+  return false;
 }
 
 /* Given a lazy-loaded string designator VAL, return the actual string.
@@ -3933,7 +3936,8 @@ read0 (Lisp_Object readcharfun, bool locate_syms)
 	    /* #@NUMBER is used to skip NUMBER following bytes.
 	       That's used in .elc files to skip over doc strings
 	       and function definitions that can be loaded lazily.  */
-	    skip_lazy_string (readcharfun);
+	    if (skip_lazy_string (readcharfun))
+	      return unbind_to (base_pdl, Qnil);
 	    goto read_obj;
 
 	  case '$':




Reply sent to Mattias Engdegård <mattiase <at> acm.org>:
You have taken responsibility. (Fri, 26 May 2023 09:23:01 GMT) Full text and rfc822 format available.

Notification sent to richard newton <richardn26 <at> gmail.com>:
bug acknowledged by developer. (Fri, 26 May 2023 09:23:02 GMT) Full text and rfc822 format available.

Message #13 received at 63722-done <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 63722-done <at> debbugs.gnu.org, richard newton <richardn26 <at> gmail.com>
Subject: Re: bug#63722: 29.0.91; (elisp) Skip to end #@00 does not work
Date: Fri, 26 May 2023 11:22:40 +0200
25 maj 2023 kl. 20.44 skrev Eli Zaretskii <eliz <at> gnu.org>:

>> With emacs 29.0.91 pretest, the "skip to end" syntax #@00 no longer seems to work. For example,
>> with the three lines below in a buffer (eval-buffer) gives the error - End of file during parsing. With
>> previous emacs versions it did not complain.
>> 
>> (setq testStr "zz")
>> #@00
>> should be ignored

Thank you for reporting this. The undocumented #@00 behaviour has indeed been co-opted by parts of the community as an 'pretend end-of-file occurs here' mechanism, but it actually works as if only the value `nil` were left in the buffer. This is fine in files containing Lisp source where a top-level nil has no effect, but could cause trouble if used in Lisp data files.

Obviously we are going to keep the old reader behaviour for compatibility for now since there is little to gain from not doing so.

Ideally we should stop handling comments and whitespace in readevalloop because the actual reader (read0) is perfectly capable of doing that. We need a way to distinguish 'EOF before anything could be read' from 'EOF when we have read an incomplete value', both of which currently signal `end-of-file`. Not sure how best to do that in a compatible way, however.

> Does the below look like the correct way of fixing this regression?

Thank you and yes, roughly speaking -- a fix has now been pushed to emacs-29, and I'm closing the bug.





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#63722; Package emacs. (Fri, 26 May 2023 09:44:01 GMT) Full text and rfc822 format available.

Message #16 received at 63722 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: 63722 <at> debbugs.gnu.org
Cc: mattiase <at> acm.org, richardn26 <at> gmail.com
Subject: Re: bug#63722: 29.0.91; (elisp) Skip to end #@00 does not work
Date: Fri, 26 May 2023 11:43:23 +0200
Mattias Engdegård <mattiase <at> acm.org> writes:

Hi Mattias,

> The undocumented #@00 behaviour has indeed been co-opted by parts of
> the community as an 'pretend end-of-file occurs here' mechanism,

Should this be documented then?

Best regards, Michael.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#63722; Package emacs. (Fri, 26 May 2023 09:52:01 GMT) Full text and rfc822 format available.

Message #19 received at 63722 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: richardn26 <at> gmail.com, 63722 <at> debbugs.gnu.org
Subject: Re: bug#63722: 29.0.91; (elisp) Skip to end #@00 does not work
Date: Fri, 26 May 2023 11:51:43 +0200
26 maj 2023 kl. 11.43 skrev Michael Albinus <michael.albinus <at> gmx.de>:

>> The undocumented #@00 behaviour has indeed been co-opted by parts of
>> the community as an 'pretend end-of-file occurs here' mechanism,
> 
> Should this be documented then?

I don't think we should do that right now -- the behaviour (read as nil) is not ideal and should not be made permanent; we still have the option to change it (but not in emacs 29, of course).

We could also come up with a less obscure replacement syntax, given that there may be a genuine need.





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#63722; Package emacs. (Fri, 26 May 2023 09:57:01 GMT) Full text and rfc822 format available.

Message #22 received at 63722 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Mattias Engdegård <mattiase <at> acm.org>
Cc: richardn26 <at> gmail.com, 63722 <at> debbugs.gnu.org
Subject: Re: bug#63722: 29.0.91; (elisp) Skip to end #@00 does not work
Date: Fri, 26 May 2023 11:56:12 +0200
Mattias Engdegård <mattiase <at> acm.org> writes:

Hi Mattias,

>>> The undocumented #@00 behaviour has indeed been co-opted by parts of
>>> the community as an 'pretend end-of-file occurs here' mechanism,
>> 
>> Should this be documented then?
>
> I don't think we should do that right now -- the behaviour (read as
> nil) is not ideal and should not be made permanent; we still have the
> option to change it (but not in emacs 29, of course).
>
> We could also come up with a less obscure replacement syntax, given
> that there may be a genuine need.

Everything right. But it is used meanwhile in the wild ... perhaps we
should document then, that this usage is deprecated?

Best regards, Michael.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#63722; Package emacs. (Fri, 26 May 2023 10:36:01 GMT) Full text and rfc822 format available.

Message #25 received at 63722 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: mattiase <at> acm.org, richardn26 <at> gmail.com, 63722 <at> debbugs.gnu.org
Subject: Re: bug#63722: 29.0.91; (elisp) Skip to end #@00 does not work
Date: Fri, 26 May 2023 13:36:01 +0300
> Cc: richardn26 <at> gmail.com, 63722 <at> debbugs.gnu.org
> From: Michael Albinus <michael.albinus <at> gmx.de>
> Date: Fri, 26 May 2023 11:56:12 +0200
> 
> Mattias Engdegård <mattiase <at> acm.org> writes:
> 
> >>> The undocumented #@00 behaviour has indeed been co-opted by parts of
> >>> the community as an 'pretend end-of-file occurs here' mechanism,
> >> 
> >> Should this be documented then?
> >
> > I don't think we should do that right now -- the behaviour (read as
> > nil) is not ideal and should not be made permanent; we still have the
> > option to change it (but not in emacs 29, of course).
> >
> > We could also come up with a less obscure replacement syntax, given
> > that there may be a genuine need.
> 
> Everything right. But it is used meanwhile in the wild ... perhaps we
> should document then, that this usage is deprecated?

I see no reason to deprecate it, let alone remove it, FWIW.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#63722; Package emacs. (Fri, 26 May 2023 11:56:02 GMT) Full text and rfc822 format available.

Message #28 received at 63722 <at> debbugs.gnu.org (full text, mbox):

From: Mattias Engdegård <mattiase <at> acm.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Michael Albinus <michael.albinus <at> gmx.de>, richardn26 <at> gmail.com,
 63722 <at> debbugs.gnu.org
Subject: Re: bug#63722: 29.0.91; (elisp) Skip to end #@00 does not work
Date: Fri, 26 May 2023 13:55:14 +0200
26 maj 2023 kl. 12.36 skrev Eli Zaretskii <eliz <at> gnu.org>:

>> Everything right. But it is used meanwhile in the wild ... perhaps we
>> should document then, that this usage is deprecated?
> 
> I see no reason to deprecate it, let alone remove it, FWIW.

I prefer neither documenting nor deprecating it now.
If someone asks me on the record, I will neither confirm nor deny its existence.





bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Sat, 24 Jun 2023 11:24:06 GMT) Full text and rfc822 format available.

This bug report was last modified 306 days ago.

Previous Next


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