Cluster of scalars isn't pretty-printed

[Jim Kring]

If I convert a cluster of scalars to JSON, like this…

‌

The pretty-printed output looks like this:

{"foo":1,"bar":"hello"}

‌

However, I expected it to look like this:

{
  "foo": 1,
  "bar": "hello"
}

‌

I’ve attached a VI Snippet of the screenshot above.

[James Powell]

If you look in the code, I choose to not pretty print small objects, less than 40 characters if I remember, which is sometimes better but sometimes worse.

[Jim Kring]

No doubt, “pretty” is in the eye of the beholder

My use case:

Each cluster element should be on a separate line, in order to make text-diffing and merging of configuration file settings easier (e.g. when kept in source code control).

I wonder if the “less than 40 characters“ setting could be an input the JSONtext.

And (thinking out loud), if we want to avoid having too many VI inputs on the API, perhaps passing in a configuration object/dictionary might be a solution.

‌

[James Powell]

Could this be an application different than “Pretty Print”? “Line Format”, or something? What would be the set of rules that you would want in this use case? For example, do you want indenting? That’s a lot of useless extra characters as far as the SCC system is concerned. What about commas? Adding an extra element to the Object adds a comma. For Pretty Print, the comma goes at the end of the previous line, but that is a change to that line as far a SCC is concerned. It makes more sense to have the comma at the front of the new line, so the change is just an added line.

{
"foo":1
,"bar":"hello"
,"new thing":true
}

I ask this, as I want to determine if a new method is a better thing than adding customization to the “Pretty Print” function.

[James Powell]

Another option is adding the number of characters as an input to “Pretty Print.vi”, as then Users can also use this to increase the number above 40.

[James Powell]

Could also add a Conditional Disable, to control teh number of characters (with options of zero, 40, 80, 120, etc.). This would have teh advantage of controlling Pretty Print formatting everywhere (not just Pretty Print.vi), but would be a global compile-time setting.

[Felipe P.]

Hi, I have come to the same issue this month, when I was doing some tests with this library.
Apparently my expected result is the same as Jim mentioned, which follows some of the outputs from different web sites, and VS Code plugins (identation included).

Right now I am using a tool that I created some time ago, only for that (https://gitlab.com/felipe_public/labview-shared-libraries/json-pretty-printer.lvlib). The algorithm is extracted from somewhere else, and it is within the code explaining all the steps.
My idea is to drop using this library in favor of JSONtext, but right now is a no go.

About the implementation ideas, I believe adding an extra input would be the best way to all users, it is another input indeed, but it makes sense to keep the function useful for everyone.

[James Powell]

Adding a “Line Size” input to “Pretty Print.vi” in the next version. Set it to zero for teh behavior you want.

‌

Note that I am not changing “Reformat.vi”; use teh newer, more capable and faster, “Pretty Print.vi”

[Jim Kring]

This is great news! Thanks, James.

Felipe: I've used your pretty printer and it's helped a lot.

[Felipe P.]

Well done James. That’s a really good news.

Jim: Thanks for the support. It makes me happy that the code helped at least one more community member.