Subject: Re: bug#79192: json parsing error position reform

From: Mattias Engdegård <[email-masked]>
Date: Mon, 11 Aug 2025 14:22:01 +0200

10 aug. 2025 kl. 14.03 skrev Eli Zaretskii <[email-masked]>:

> 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.