GNU bug report logs -
#79192
json parsing error position reform
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
On Thu, Aug 7, 2025 at 12:33 PM Mattias Engdegård <
mattias.engdegard <at> gmail.com> wrote:
> 7 aug. 2025 kl. 18.17 skrev Eli Zaretskii <eliz <at> gnu.org>:
>
> > 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.
[Message part 2 (text/html, inline)]
This bug report was last modified 7 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.