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

From: Eli Zaretskii <[email-masked]>
Date: Thu, 07 Aug 2025 21:22:46 +0300

> From: Mattias Engdegård <[email-masked]>
> Date: Thu, 7 Aug 2025 18:32:34 +0200
> Cc: [email-masked]
> 
> 7 aug. 2025 kl. 18.17 skrev Eli Zaretskii <[email-masked]>:
> 
> > How is providing helpful data about the locus
> > of an error "useless"?
> 
> Sorry, I didn't intend to sound facetious. What I meant is that the line and column are not likely to help current or future users in any significant way:
> 
> - If anyone would need the point of error, it would almost certainly be as a position, not line and column.
> - In the unlikely case that the line and column would be called for, they can easily be computed by the user.
> - That computation would be done in Lisp, which is easier; ours would have to be in C.
> - Line and column aren't universally well-defined (start at 0 or 1? How are columns defined? Tabs? Multibyte chars? Combining chars?). The user is better-placed to use a definition that suits the requirements.
> - But so far, nobody seems to have a need the point of error in the first place.
> 
> Therefore it very much looks like gold-plating. In other words, we'd give a mistake in the first implementation an unwarranted life extension when we had a chance to drop it without consequences.

Every tool that reports errors or hits shows line numbers, and
sometimes also column numbers.  So it looks like a reasonable thing to
expect.  Whether they are zero-based or 1-based we could decide by
looking at what other tools do (I think 1-based), but that's not the
important part.

As for calculating lines and columns, I indeed had in mind a call to
some Lisp function, which is done only when we are about to signal an
error.  We don't have to do that in C.