GNU bug report logs -
#79192
json parsing error position reform
Previous Next
Full log
View this message in rfc822 format
> From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
> Date: Thu, 7 Aug 2025 18:32:34 +0200
> Cc: 79192 <at> debbugs.gnu.org
>
> 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.
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.
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.