GNU bug report logs -
#79192
json parsing error position reform
Previous Next
Full log
Message #38 received at 79192 <at> debbugs.gnu.org (full text, mbox):
> From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
> Date: Sun, 10 Aug 2025 13:50:00 +0200
> Cc: 79192 <at> debbugs.gnu.org,
> Dmitry Gutov <dmitry <at> gutov.dev>,
> Ship Mints <shipmints <at> gmail.com>
>
> 9 aug. 2025 kl. 16.16 skrev Eli Zaretskii <eliz <at> gnu.org>:
>
> > What are the practical problems of calculating the line number only
> > when an error is about to be reported? That shouldn't affect
> > performance, so I don't see why we would be against doing that.
>
> What are the pressing needs for doing that?
That we produce this information now. Removing it would be a breaking
change, and I'd like to avoid that.
> Of the callers of the json parser, not all catch its errors specifically.
>
> Of those that do, most(*) do not use the position information.
> (*) currently 100 %
>
> Of those that would use the position information, many wouldn't need line and column numbers.
>
> Want to position the cursor at the point of the parse error? Don't need line or column.
> Want to use faces to show what has been successfully parsed and what has not? Don't need line or column.
> Want to write a flymake tool that reports the error? Don't need line or column.
>
> We should not compute line and column in the json parser because there's no need, and it wouldn't be good API design. Adding code willy-nilly just because it doesn't slow down normal use much isn't good enough a reason.
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.
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.