Separate JSON and "JSON with comments" syntaxes?

[FichteFoll]

I've been thinking about this for quite a while now. It has always bothered me that Sublime Text's JSON syntax definition allows JavaScript-style comments, which are a clear violation of the standard. Users hand-editing JSON files with Sublime Text might be confused why whatever is parsing the .json file chokes on the comments that ST highlighted perfectly fine.

In order to make things more canon, I suggest introducing a different syntax for Sublime Text configuration files named "JSON with comments" or "JSONC" that will keep the features of the current JSON definition, while the "JSON" syntax gets comment support removed.

I tried googling for a possible standard for this that might have emerged over the time, but there doesn't seem to be any. I found:

• a commentjson python module (also for npm as comment-json)
• a npm package named json5, which makes additional changes to its JSON standard such as allowing trailing commas (same as ST3), single quotes, unquoted object keys and more number formats however

Opinions?

[MattDMo]

Why not tighten the current JSON definition to exclude comments (and all the other additions) and strictly adhere to the JSON standard? We could then adapt the PackageDev syntax definitions into Sublime's core? This way, all users have default highlighting of .sublime-settings, .sublime-keymap, .sublime-mousemap, and all of the other pseudo-JSON files.

[FichteFoll]

Why not tighten the current JSON definition to exclude comments

Yes, that is the plan.

I wouldn't object having specific syntax definitions for ST's configuration in ST's core, but not the current ones in PackageDev. I intend to redo them anyway. Will and Jon will need to decide on that however.

[rchl]

I personally wouldn't be so happy about such change as I work with JSON files where comments are allowed. That is with chrome extensions whose manifest.json file accepts comments and also with chromium code itself which uses JSON for many things and uses https://github.com/open-source-parsers/jsoncpp to parse them which allows comments.

Of course if two separate syntaxes would be included in Sublime, then it would be easy to change for the more lax parser to be the default, so it wouldn't be that much problem.

[jskinner]

There's a clear cost to this: forcing the user to change from JSON to JSON-with-comments when they're dealing with a file that allows comments. Most users won't know this is an option, so they'll just see ugly syntax errors. Users who do know to do this will still be faced with more manual work.

Given that it's making users life worse, I'd want to see a pretty strong benefit, but I'm struggling to see any at all.

[FichteFoll]

@jps, how many "JSON formats" out there outside of ST's resource files do you of that allow comments and what file extension do they use? I don't remember a single encounter, personally.

Since the resource files are known to us and they even use different file extensions, it's easy to open them with the correct syntax.

[michaelblyons]

@jps, how many "JSON formats" out there outside of ST's resource files do you know of that allow comments and what file extension do they use? I don't remember a single encounter, personally.

Config for VS Code (and maybe Atom?). The VSC ones are *.json extension.

Since the resource files are known to us and they even use different file extensions, it's easy to open them with the correct syntax.

True.

I'm not here to make a case for either side. I griped a little at another syntax highlighting project to do what @FichteFoll wants, but the eventual compromise was basically what ST already does now.

I was mostly annoyed there that there wasn't any lenient, comment-permitting JSON option at all, and we (that is to say "users of Discourse," like ST's forum) had to use Javascript highlighting instead, where keys were marked as strings rather than something special.

[keith-hall]

have you seen https://json5.org/ (kinda mentioned in the OP) and https://hjson.github.io/ ? they go beyond just adding comment support though and the latter certainly uses a different file ext, not sure about the former.

[FichteFoll]

Config for VS Code (and maybe Atom?).

Atom primarily uses CSON afaik (which is the same but in CoffeeScript) with the .cson extension. At least that's what the flight manual says about snippets and keymaps. It also seems to support JSON but I don't know about comments within.

[jrappen]

Could anyone interested in having this issue fixed please test whether #3097 does indeed fix it? Thanks.