Add colors to JSON printer

[mavam]

This PR brings a few JSON printer changes:

1. Make --pretty the default for write json
2. Ditch --pretty in favor of the opposite -c|--compact-output (like jq)
3. Add -C|--color-output and -M|--monochrome-output to explicitly set the color.

Unlike jq, there's currently no auto-detection of colors. You have to provide -C for now. While we could do TTY detection, it's a bit more complicated from the printer's perspective, because we need to know the corresponding saver in order to make a call. If it's stdout, we can add colors, if it's a file, we can't.

### Tasks
- [x] Implement styling logic
- [x] Support clear and colored styles
- [x] Add changelog entry
- [x] Update docs
- [x] Adapt unit tests
- [x] Adapt integration tests

[tobim]

I'm not sure I like these new defaults. I guess I don't have a strong opinion.

Can you please add support for NO_COLOR? An equivalent Tenzir specific config option should also be available.

[mavam]

I'm not sure I like these new defaults. I guess I don't have a strong opinion.

These are jq and that's the de-facto UX for JSON processing. If you don't have a strong opinion, I would strongly recommend to follow their defaults.

Can you please add support for NO_COLOR? An equivalent Tenzir specific config option should also be available.

I added support for NO_COLOR in the style detection, but don't know what you mean by "config option".

[tobim]

but don't know what you mean by "config option".

Something that I can add to my tenzir.yaml to make it explicit. @jachris please chime in if you already considered a generic solution for configuring operators.

[mavam]

Something that I can add to my tenzir.yaml to make it explicit.

This is out of scope for this PR. We don't have something like that yet.

I also don't think operators should be able to configured in an external file. Then you can no longer share pipelines and assume they do what you'd expect.

[jachris]

please chime in if you already considered a generic solution for configuring operators.

Not really, but since every operator is a plugin, you could use the plugin configuration for that.

I also don't think operators should be able to configured in an external file. Then you can no longer share pipelines and assume they do what you'd expect.

We have the same problem with environment variables like NO_COLOR though. But in general, I tend to agree that we want to avoid changing the observable behavior with config options (unless it leads to an error, like allow-unsafe-pipelines).

[tobim]

I guess not providing config options for operators is fine for most cases, purely cosmetic options like NO_COLOR should be exempt though.

[dominiklohmann]

This is working well in practice. Thanks!

[mavam]

@dominiklohmann I saw you sneaking in the --omit-* commit! Planned that for another PR. But oh well, @satta will be happy. 😉

[dominiklohmann]

Hah, I just noticed that being documented but not implemented when reviewing this PR, so I asked Daniel whether it was okay to just push it on top. Felt quicker than writing a story for it.

[satta]

I will be happy indeed :) Thanks!

BTW, are you using isatty() or something similar to detect whether you're printing to a terminal or not and deactivate colors in the latter case? I found that useful in order to avoid escape sequences in redirected JSON output.

[dominiklohmann]

BTW, are you using isatty() or something similar to detect whether you're printing to a terminal or not and deactivate colors in the latter case? I found that useful in order to avoid escape sequences in redirected JSON output.

We discussed somewhere in a thread for this PR that we actually need to pass that information up from the last operator, and wrote a follow-up story for that. For now, colors are opt-in.

E.g., if you run this:

tenzir '… | write json | save file foo.json'

Then the information of whether or not we're printing to a terminal must be passed from save to write. We talked about the how, but it's for sometime in the future because write cannot reliably detect that on its own.

[satta]

I see, true!