Subject: bug#62020: closed (Re: bug#62020: Lisp reader: dotted pair notation not working when initial elements are omitted)

From: [email-masked] (GNU bug Tracking System)
Date: Sun, 12 Mar 2023 17:11:02 +0000

Your bug report

#62020: Lisp reader: dotted pair notation not working when initial elements are omitted

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
62020: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62020
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#62020: Lisp reader: dotted pair notation not working when initial elements are omitted
From: Mattias Engdegård <[email-masked]>
To: Eli Zaretskii <[email-masked]>
Cc: [email-masked], Stefan Monnier <[email-masked]>, Federico Tedin <[email-masked]>
Date: Sun, 12 Mar 2023 18:10:39 +0100
List-Id: <debbugs-submit.debbugs.gnu.org>

11 mars 2023 kl. 13.19 skrev Eli Zaretskii <[email-masked]>:

>>> Documentation changes are always fine for a release branch, but I'd
>>> prefer to discuss a specific patch, if you don't mind posting one.
>> 
>> Not at all. There's not much to see here -- the minimal change would just remove a paragraph:
> 
> OK, thanks.

Pushed to emacs-29.

Subject: Lisp reader: dotted pair notation not working when initial elements are omitted
From: Federico Tedin <[email-masked]>
To: [email-masked]
Date: Tue, 7 Mar 2023 02:14:02 +0100
List-Id: <debbugs-submit.debbugs.gnu.org>

According to the Elisp docs
(https://www.gnu.org/software/emacs/manual/html_node/elisp/Dotted-Pair-Notation.html),
one should be able to evaluate e.g.:
    (. 1)
to:
    1

This works correctly in Emacs 28.1 However, in the emacs-29 branch
(bd07cec) this results in:
    *** Read error ***  Invalid read syntax: "."

Since the description in the docs are the same in the emacs-29 I
assume this is a bug.
I believe this may have been caused by the changes implementing the
nonrecursive Lisp reader.
I believe the fix would be roughly:
- in read0 (lread.c), when handling c == '.', ensure we handle not
only the case where the top of the read stack is RE_list but *also*
RE_list_start.
- if the top of the stack was effectively RE_list_start, then the top
of the stack needs to be manipulated somehow so that at the end of
read0 the correct value is returned, when emptying the stack.