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

From: Stéphane Marks <[email-masked]>
Date: Thu, 7 Aug 2025 13:15:18 -0400

On Thu, Aug 7, 2025 at 12:33 PM Mattias Engdegård <
[email-masked]> wrote:

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

Most of the json I deal with (not in Emacs, though, or yet) is "minified"
and has no newlines.  The position would be all I could reasonably use for
minified json as the line number would always be 1 and the column number
would, I'd hope, equal the position of an error.