Repository navigation
Separate JSON and "JSON with comments" syntaxes? #285
Description
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
commentjsonpython module (also for npm ascomment-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?
Activity
MattDMo commentedon Apr 15, 2016
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
PackageDevsyntax 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 commentedon Apr 15, 2016
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 commentedon Apr 26, 2016
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 commentedon Feb 10, 2020
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 commentedon Feb 13, 2020
@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 commentedon Feb 13, 2020
Config for VS Code (and maybe Atom?). The VSC ones are
*.jsonextension.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 commentedon Feb 13, 2020
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 commentedon Feb 13, 2020
Atom primarily uses CSON afaik (which is the same but in CoffeeScript) with the
.csonextension. 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 commentedon Oct 22, 2021
Could anyone interested in having this issue fixed please test whether #3097 does indeed fix it? Thanks.
[JSON] Rewrite syntax
[JSON] Rewrite syntax
[JSON] Rewrite syntax
[JSON] Rewrite syntax
[JSON] Rewrite syntax
[JSON] Rewrite syntax
[JSON] Rewrite syntax
[JSON] Rewrite syntax
[JSON] Rewrite syntax
[JSON] Rewrite syntax
[JSON] Rewrite syntax
[JSON] Rewrite syntax