GNU bug report logs - #79192
json parsing error position reform

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: dmitry <at> gutov.dev, shipmints <at> gmail.com, 79192 <at> debbugs.gnu.org
Subject: Re: bug#79192: json parsing error position reform
Date: Mon, 11 Aug 2025 16:40:40 +0300

> From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
> Date: Mon, 11 Aug 2025 14:22:01 +0200
> Cc: 79192 <at> debbugs.gnu.org,
>  Dmitry Gutov <dmitry <at> gutov.dev>,
>  shipmints <at> gmail.com
> 
> 10 aug. 2025 kl. 14.03 skrev Eli Zaretskii <eliz <at> gnu.org>:
> 
> > I'm against incompatible changes if we can avoid that.  Our abilities
> > to be sure that no one uses some feature are very limited and fail
> > time and again.  So if we can keep this feature without the
> > performance hit, I'd very much prefer it.
> 
> 
> Yes, that's clearly a valid concern and I agree with you in principle. When I started working on this I assumed that I'd have to include the line and column calculations because they were there before.
> 
> And while it's theoretically conceivable that there might be a use in a file on someone's private disk somewhere, the fact that no public use could be found at all, that it was never documented, and that it had only been available for a comparatively short time (since the release of Emacs 30), all taken together makes it very unlikely that anything would depend on it.
> 
> So it seems to be an opportunity to fix a mistake before being too late. I remember asking the original author of the json parser about it at the time and got the impression that he'd found it useful at some point while debugging the parser itself, but it really didn't make much sense and I made a mental note to get rid of it before the release of Emacs 30. Goes to show how reliable my mental notes can be.
> 
> As other people pointed out, the primary use of the json parser is to decode data generated by other programs and these cram together everything without whitespace for bandwidth efficiency, like our own json serialiser does.
> 
> A minor point: the parser also reports the error position (the third error parameter, after the line and column) in characters even when the input was a unibyte string or buffer. That doesn't seem right either and would refer to the wrong position in the string or buffer so I'm fixing that bug while at it.

I hear you, but then counting lines in Lisp is simple, and we have
functions ready to do that.  So how hard is it to call one of those
functions from the parser, when it detects and error and is about to
signal?

Previous Next

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