language-json: Provide a setting to highlight all ERROR nodes as invalid

[aph3rson]

Have you checked for existing feature requests?

• Completed

Summary

The tree-sitter highlights.scm for language-json deliberately suppresses error highlighting for malformed JSON. The only error case that receives an invalid.illegal scope is a stray comma inside an ERROR node:

(ERROR "," @invalid.illegal.comma.json)

This means unquoted keys, missing brackets, trailing garbage, bare identifiers, etc. produce no visual feedback, even though the tree-sitter parser correctly detects them as ERROR nodes.

The existing comment in the source acknowledges this is intentional ("it might be a distraction while typing"), but there's no user-facing way to opt into full error highlighting. There should be a setting (similar to language-json.allowCommentsInJsonFiles) that lets users choose whether ERROR nodes get the invalid.illegal scope.

What benefits does this feature provide?

Users editing JSON get immediate visual feedback when their document is malformed. This is especially valuable for configuration files where a subtle syntax error (missing quote, extra bracket, trailing comma in strict JSON) can cause silent failures downstream. The parser already detects these errors; this just surfaces them to the user.

Any alternatives?

1. Monkeypatching in init.js - Users can hook into onDidActivatePackage and attempt to replace the highlights query at runtime. This is fragile, depends on internal APIs (setQueryForTest, getQuery), and could break between releases.

2. Disabling tree-sitter entirely for JSON - Setting useTreeSitterParsers: false in config falls back to the TextMate grammar, which does mark more error cases. But this loses all the benefits of tree-sitter (better structure-aware highlighting, folding, indentation).

3. A community package - Possible, but grammar queries can't be partially overridden by a community package without replacing the entire bundled language-json. Since this is a one-line change gated behind a setting, it belongs in core.

The ideal solution is a setting like language-json.highlightErrors (default true or false, your call) with a conditional query:

((ERROR) @invalid.illegal.json
  (#is? test.config "language-json.highlightErrors"))

Other examples:

VS Code's built-in JSON language support highlights all JSON syntax errors inline by default, with red squiggly underlines on malformed regions. Neovim's tree-sitter integration applies @error highlight captures to all ERROR nodes by default, which themes then render as visible errors. Both treat "show the user when their JSON is broken" as baseline expected behavior.

[savetheclocktower]

This is fair. But I think the long-term fix is to make something like pulsar-ide-json a core package instead of a thing you just have to know about.

It was ages ago that I made that choice, but I think it was because the highlighting wasn't actually helpful in most cases. That's my experience with Tree-sitter's error recovery — when a parser is as strict as the JSON parser and gets into an error state, the fact that it errored is significant (and useful to the user) but the actual contours of the ERROR node are not. They often don't point to the actual problem.

This is still a fair suggestion, and I'll probably implement it soon. But pulsar-ide-json uses the exact same language server that VS Code uses for JSON language support, and it's probably the thing that most closely delivers what you're asking for.