If you want human, you can look at TOML

https://github.com/toml-lang/toml

Its the thing Pipfile uses.

The point is, don't invent file types!

It's interesting. can you have @js more than once? can you have @app more than once? pretty sure ಠ-ಠ is a valid app name, but ಠ_ಠ isn't. i also can't quite tell how to say map of maps. i'd guess it's

    @this-section-has-a-map
    hello-world
      name child-map
        ಠ-ಠ a
        ಠ_ಠ b

but it's hard to tell. Also, i'm not exactly a fan of { "_comment": "this is a comment" }, but i've run into several situations with yaml where i want to build a tool to rewrite a bunch at once, but since comments have no representation in the parse tree i have to do goofy vim macros to do my edits. since _comment is in the tree, i can add more keys without trashing the existing comments.

Hey, one of the .arc authors and maintainers here.

Only one of each section is what we designed for though the validations for that might be broken (and if so we can fix right away). Nesting is limited to one level. No need for more that we've seen yet.

I'm a proponent for JSON but agree that the lack of comments are one of the more annoying things I frequently run into.

edit--Especially when it comes to users editing config files. Imagine a new user trying to edit a web server/db/.bashrc file that didn't have comments to help out?

Rather than inline-comments I've always had separate documentation. This helps prevent trying to cram all the edge case caveats and everything into the configuration file.

inline comments are handy for pointing out "non standard" configuration settings for your enviroment. especially on production systems.

It aids in troubleshooting greatly to have inline comments point out "odd" settings in configuration without having to look at seperate (usually old) documentation.

Then use json5. Super weak excuse. Or use yaml or some other format and pipe it into some to-json converter.

Also, json has json schema which tools like VS Code support. They can autocomplete your config. Pretty promising over most other tooling.

But coming up with your own config has pretty much all the downsides. Yeah, you can invent some cuter syntax. But now your users can't even get syntax highlighting in their editor. Awful UX.

JSON5's support for unquoted keys seems like a misfeature. Not to mention that (by its nature) it has the same (lack of) support burden as any other new configuration format. If you're going to go through that frustration and incompatibility, why not pick something better suited to the job?

> JSON5's support for unquoted keys seems like a misfeature.

Seen plenty of JSON without quoted keys before that just seemed to work, so depends on parser.