GNU bug report logs - #79192
json parsing error position reform

Previous Next

Package: emacs;

Reported by: Mattias Engdegård <mattias.engdegard <at> gmail.com>

Date: Thu, 7 Aug 2025 15:21:01 UTC

Severity: normal

Full log


Message #32 received at 79192 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mattias Engdegård <mattias.engdegard <at> gmail.com>
Cc: dmitry <at> gutov.dev, shipmints <at> gmail.com, 79192 <at> debbugs.gnu.org
Subject: Re: bug#79192: json parsing error position reform
Date: Sat, 09 Aug 2025 17:16:56 +0300
> From: Mattias Engdegård <mattias.engdegard <at> gmail.com>
> Date: Sat, 9 Aug 2025 16:08:12 +0200
> Cc: 79192 <at> debbugs.gnu.org,
>  Dmitry Gutov <dmitry <at> gutov.dev>,
>  Ship Mints <shipmints <at> gmail.com>
> 
> 7 aug. 2025 kl. 20.22 skrev Eli Zaretskii <eliz <at> gnu.org>:
> 
> > Every tool that reports errors or hits shows line numbers, and
> > sometimes also column numbers.  So it looks like a reasonable thing to
> > expect.
> 
> But the json parser isn't a tool, it's a low-level primitive that can be used to make tools.
> Having it produce line and column numbers makes as much sense as doing that from `re-search-forward`.
> Or, if you prefer, from one of our two (three?) XML parser APIs. It just not how APIs are designed.

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.




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.