Don't include ANSI codes when output is non-interactive

[Fryuni]

Use Case/Motivation

When stdout is not a tty it would be better to not output any ANSI special codes (for colors).

This allows piping entries from JRNL to other CLI tools, like Charm's Mods to use with a chatbot.

Example Usage

jrnl -2 | mods 'extract action items from these notes'

What is sent as prompt is this:

❯ mods -s a893ef5

  Prompt: extract action items from these notes. Format the response as
  markdown without enclosing backticks.

  [1m[30m2023-10-13 06:00:00 AM[0m [1m[36m<NOTE TITLE>[0m |
  <NOTE CONTENT>

  [1m[30m2023-10-13 05:09:30 PM[0m [1m[36m<NOTE TITLE>[0m |
  <NOTE CONTENT>

Other Information

This can be detected using sys.stdout.isatty

[micahellison]

Hi @Fryuni, thanks for filing this. I am leaning against implementing this feature, and I want to document why here, but I also want to be open to input from the community on this, so I'm tagging this as a discussion for now.

jrnl has two categories of output formats: "display formats" intended for human consumption, and "data formats" intended for machine consumption.

The default format pretty is one of those display formats, and even when it's piped, there are sometimes use cases in which people would like to preserve colors. In fact, when colors were accidentally removed while piping, it broke someone's process and led to them filing a bug (#1819).

The data formats, however, will never include color codes. In particular, the text format is ideal for this kind of piping, since it uses the same format that jrnl uses to store the journal. You can apply this format by adding --format text to your jrnl call, or you can even set it by default by adding display_format: text to your config file.

If you want the best of both worlds with having to add the --format arg to your piped calls, you could also define the same journal twice in your config file, once for each format:

journals:
  home:
    journal: ~/home.txt
    display_format: pretty
  homepipe:
    journal: ~/home.txt
    display_format: text

While I think these workarounds are relatively simple, I also know that all of these approaches involve extra steps that come as an unwelcome surprise to people expecting color suppression while piping. After all, lots of CLI programs suppress colors when piping, and I think there's a real benefit to mimicking the default behaviors of popular CLI programs so jrnl is easier to pick up for new users. Maybe there's a compromise out there that has already been implemented in some of those programs. I'm open to examples and suggestions.

[Fryuni]

A somewhat simple compromise to have the automatic color suppression by what you said would be to have a format (say auto-pretty) that equals to pretty on a tty and equals to text when not.

Keeping the default as is for backwards compatibility of course

[wren]

@Fryuni How about if we introduce a new color setting? Something like what bat does (see --color here).

--color <when>

    Specify when to use colored output. The automatic mode only enables colors if
    an interactive terminal is detected. Possible values: *auto*, never, always.

This would allow us to not bake in the preference to any format, but still allow the flexibility for users to choose their preference.

[Fryuni]

That sounds good. That colors option could be persisted on the configuration as well rihgt? Not just as a CLI flag