bug#61043: 30.0.50; `json-ts-mode': invalid font lock rule

[Mickey Petersen]

Drew Adams <drew.adams@oracle.com> writes:

>> There's a comment font lock rule in `json-ts-mode'. However, that is
>> illegal and againt the JSON spec, and indeed the search query fails
>> because `comment' is not a valid node type.
>
> Caveat: Not following this thread, ignorant of
> tree sitter, and probably ignorant of the use-
> case context.
>
> JSON syntax per its spec(s) is one thing.
> JSON out there in the wild is something else.
>
> There are zillions of JSON documents that
> aren't well-formed per the specs.  And lots of
> apps that create and use such data.
>

Agreed. Sadly, the JSON grammar in TS does not support comments, and
so no comment support is possible. OTOH, because it is strict, it'll
catch errors like trailing commas, etc.

For 'lax' JSON, the best option is Javascript.

> As a result, in the real world, tools that we
> expect to be useful for working with real data
> need to be _able_ (optionally) to handle at
> least the more common such deviations from
> what the specs prescribe.
>
> One way to do that is to have a variable/mode
> that controls the kind(s) of well-formedness
> you want to enforce.  E.g., have two modes:
> lax and strict.  Or let functions dealing with
> data have an optional arg that specifies the
> syntax (lax or strict) to enforce.
>
> And of course, we'd want to document just what
> "lax" mode means: what syntax departures from
> the specs our lax syntax tolerates.
>
> A lax syntax, for example, often reflects the
> JavaScript syntax for object fields; boolean
> and null values aren't case-sensitive; and
> it's more permissive with respect to numerals,
> whitespace, and escaping of Unicode characters
> than what the JSON specs require.
>
> E.g., in JavaScript notation, a field name in
> an object literal can be, but need not be, in
> double quotation marks.  And alternatively it
> can be in single quotation marks.
>
> Other things often allowed:
>
> * An extra comma (,) after the last element of
>   an array or the last member of an object
>   (e.g., [a, b, c,], {a:b, c:d,}).
> * Numerals with leading zeros (e.g., 0042.3).
> * Fractional numerals that lack 0 before the
>   decimal point (e.g., .14 instead of 0.14).
> * Numerals with no fractional part after the
>   decimal point (e.g., 342. or 1.e27).
> * A plus sign (+) preceding a numeral, meaning
>   that the number is non-negative (e.g., +1.3).
> * Treating all ASCII control chars, and the
>   ASCII space character, as (insignificant)
>   whitespace chars.
>
> Lax-syntax JSON data is everywhere.  It's good
> to have tools that enforce the strict syntax of
> the standards, but it's also good to have tools
> that tolerate real-world, loosey-goosey JSON.
>
> HTH.