GNU bug report logs - #49944
parse-partial-sexp fails to signal an error when (> START LIMIT).

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: acm <at> muc.de, Lars Ingebrigtsen <larsi <at> gnus.org>, 49944 <at> debbugs.gnu.org
Subject: bug#49944: parse-partial-sexp fails to signal an error when (> START LIMIT).
Date: Tue, 10 Aug 2021 10:41:30 -0400

>> > We definitely have a bug here.  The documentation in the elisp manual
>> > says that the scanning is done "starting at START".  You're saying it's
>> > perfectly OK to start scanning at "LIMIT"?  This violates the doc.
>> 
>> This is what all function like this say.  To take patient zero --
>> narrow-to-region:
>> 
>> ---
>> When calling from Lisp, pass two arguments START and END:
>> positions (integers or markers) bounding the text that should
>> remain visible.
>> ---
>> 
>> Nothing here about allowing END to come before START, but it does allow
>> that, and so do most (all?) similar commands.
>
> Indeed, if the results are predictable, I see no reason not to support
> START and END in any order, as we do in many places.

I think the case of `parse-partial-sexp` is different because it
receives the argument OLDSTATE which provides the parser's state which
should apply at START.  If START and END are swapped you'll generally
get an incorrect result.

So, I don't care if we signal an error when START > END or if we "do
nothing" (as is customary in some language's `for` loops), but we should
always consider that OLDSTATE is the state that belongs with START and
hence we can't start parsing at END towards START because we don't know
what parsing state to use at END.


        Stefan

Previous Next

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