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

Previous Next

Full log

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.

Previous Next

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