sammccall added a comment. In theory, this version doesn't seem so useful - a simple JSON pretty-printer that ignores column widths etc is easy to write, doesn't need any of clang-format's infrastructure, and this isn't a particularly great one.
In practice though, not having to configure yet another tool is a big deal: > my editor and git commit hooks are just not setup to go and run jq +1, this is often the difference between using a mediocre tool and nothing. And I think for JSON data, a formulaic pretty-printer is maybe a better starting point than clang-format's context-sensitive optimizing approach. --- But we'll have to deal with the fact that this isn't going to format the way all people like. It seems reasonable to to expect to be able to: - format `["foo"]` on one line - indent with tab characters rather than spaces - format "JSON" that is incomplete/broken/has extensions (see JSON5) With my maintainer-of-`Support/JSON` hat on, I don't like the idea of these features being shoehorned into the library to make clang-format an incrementally more featureful JSON formatter. They're likely to lead to a lot of conceptual+implementation+API complexity in a library that solves its primary use cases quite well and simply. --- So if the plan is to - use this implementation to bootstrap JSON-in-clang-format - with a firm intention of replacing it with parsing/formatting logic that lives inside clang-format itself - long-term, maybe making use of `Support/JSON` long-term for some low level bits (normalizing string tokens?) but not where flexibility is needed then I think this is great. However I'm a bit leery if the plan is "land this a MVP, and then play it by ear". Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D93528/new/ https://reviews.llvm.org/D93528 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
