Please add a Pretty-Print option for arrays to stay always in one line

[mireiner]

Please add a Pretty-Printing option for arrays to stay always in one line (don't add lines) if dump() parameter > -1 or std::setw()) is set. So that only other JSON types than arrays are expanded.

Example:

json j;
j["person"]["name"] = "Glory Rainbow";
j["person"]["age"] = 61;
j["person"]["mind"] = "Easy going";
j["color"]["month"] = { 1, 3, 5, 7, 8, 10, 12};
j["color"]["order"] = {"red", "orange", "yellow", "green", "blue", "indigo", "violet"};
std::cout << j.dump(4);

Wanted output:

{
    "color": {
        "month":  [1, 3, 5, 7, 8, 10, 12],
        "order": ["red", "orange", "yellow", "green", "blue", "indigo", "violet"]
    } ,
    "person": {
        "age": 61,
        "name": "Glory Rainbow",
        "mind": "Easy going"
    }
} 

Thank you!

[xiayh1992]

en, I get into the code, jump to the dump function, get into the array switch, change o->write_character("\n ",2); to o->write_character(''); it work well for me. Thanks

[emmenlau]

Dear @nlohmann and all, I just found this nice thread and think it should be resurrected. The improved dump() that @nlohmann proposed sounds very valuable, and I think having complex configuration for dumping is reasonable and not out of scope. It seems a good balance of user-comfort and maintenance-effort. It would also be a great starting point for users that want to go further with their configuration.

In this thread I lost a bit track why an improved dump() was not merged to master. I understand it would not be a breaking change to add a new dump(config) method, and then maybe even implement the current dump(int) based on the new method (with defaults for most config values).

@nlohmann are there other problems or blockers from proceeding with your nice suggestion? Anything I can do to help move this forward?

[sumitbeniwal]

It's naive, but I think a general print behavior I want is: "Print the entire value on one line (number, string, array, object, etc). If a compound value would not fit within an X character rule width, recursively print each sub-value onto separate lines with the same logic."

Exactly what I want too. Would make big jsons more readable.

[falbrechtskirchinger]

@emmenlau If you're serious about contributing, I suggest you start a discussion.

Ideally, you'd summarize the proposed solutions from existing issues and PRs, give your thoughts, and ask for requirements, uses cases, and other feedback. That summary alone would be incredibly useful for anyone willing to work towards getting a PR merged. I know I'd appreciate it.

I favor creating an event-driven interface for dumping equivalent to sax_parse(). Both the existing dump() function and the proposed dump(config) function could then be implemented on top of this new interface and give people ultimate flexibility. For example, a user recently asked about serializing to XML, which would be trivial with such an interface.

[emmenlau]

Dear @falbrechtskirchinger ok I can now see how this is a bit more involved than what I hoped for. Your suggestion for the implementation sounds very good, but was rather hoping I could extend a bit the code of an existing PR, rather than start by gathering community feedback. While I very much agree that this is a valid path, it seems also beyond what I could stem.

What I could not understand from this discussion: Why was the original PR from @nlohmann eventually dropped?

[nlohmann]

IIRC I dropped the PR eventually, because it got more and more complex, yet only addressed some of the use cases discussed here.

I also once tried the approach sketched by @falbrechtskirchinger to have an event-based API, but I did not manage to make it fast enough to be a replacement for the status quo. In the meantime, I think it's the way to move forward as it should be flexible enough to allow everybody to plug in their faviorite way of styling JSON.

[gregmarr]

I also once tried the approach sketched by @falbrechtskirchinger to have an event-based API, but I did not manage to make it fast enough to be a replacement for the status quo.

I could see a case for supporting a "fast but not really customizable" dump() function and a "customize to your heart's content, but pay for it in performance" pretty() function if an event-based pretty() function can't be made to be comparable to the current dump() in performance. Then again, maybe pretty() is just a visit() (#1480) with something that creates JSON output.

[nlohmann]

If we would be able to create a dump based on the SAX events, we may even be able to link any of the parsers with any of the serializers - including the binary formats. The SAX events should be sufficient for a pretty printer to keep track of the depth of nesting, etc.

[nlohmann]

Let's discuss https://github.com/nlohmann/json/discussions/3594.

[BKSpek]

For anyone looking for how to do it, just change one line in serializer.hpp dump function. If (pretty_print) { // pretty print array json... } else { // print normally }

Change " if (pretty_print) " to " if (false && pretty_print) "

Maybe add a 4rth parameter to dump that takes in a bitfield of types of elements to exclude from pretty print? Then you can do something like dump(4, ' ', false, JTARRAY | JT...;

Seems easy to implement and simple to use.

[Cleroth]

This is sorely needed.