Better color detection

[CosmicHorrorDev]

Hello, first time hacking at this codebase.

So the aim of this pull request is to address the issues mentioned in #81. This was done by adding in a command line flag --color with the options always, auto, never.

--color <WHEN>

--color always (The previous behavior of tealdeer)

Will use styling as long as ANSI support is detected.

--color auto

Will use color unless:

• ANSI support isn't detected.
• The NO_COLOR environment variable exists as is the spec listed on the NO_COLOR website.
• The output isn't stdout (e.g. when the output is being piped to another program like tldr man | xclip -sel clip). This is done with the help of the newly added atty lib since it promises cross platform detection for such cases.

--color never

Disables colored output entirely.

Misc

• There was the case where the stale cache message attempted to be colored regardless of ANSI support, so I did need to tweak check_cache to make style checking consistent.
• I fixed any of the tests that seemed to be failing because of these changes: however, test_markdown_rendering seems to be failing because of changes to the tar page compared to tar-markdown.expected that I left failing as it's outside the scope of this PR.
• These changes were all tested exclusively on Linux since I don't have a rust dev environment setup for Windows and I don't have access to any other systems.

[CosmicHorrorDev]

Oh and since this changes the CLI the completions for bash/zsh/fish should be updated as well. I can look into working on that, but I won't have time till at least a week from now and also haven't setup shell completions before if anyone more knowledgable can help.

[dbrgn]

Hi, thanks for the PR! From the description your work looks very thorough 🙂

I'll try to review the PR this weekend, but can't promise anything.

I can look into working on that, but I won't have time till at least a week from now and also haven't setup shell completions before if anyone more knowledgable can help.

"Best effort" is OK (adding the strings without testing), since with #108 we'll auto-generate those completions anyways.

These changes were all tested exclusively on Linux since I don't have a rust dev environment setup for Windows and I don't have access to any other systems.

CI runs on macOS and Windows as well. Maybe we can create integration tests for some of these cases?

test_markdown_rendering seems to be failing because of changes to the tar page

That was fixed in #110, I simply forgot to merge that one. Sorry about that.

--color always (The previous behavior of tealdeer)
Will use styling as long as ANSI support is detected.

I wonder if always should use ANSI support detection at all... That somehow seems to contradict the term "always".

[CosmicHorrorDev]

Thinking back on it now it does seem deceptive to have a case where --color always doesn't attempt to use color.

I should be able to find the time to:

1. Switch color always to always attempt to style
2. Update the completions for the new flag
3. And add in some integration tests to ensure correct behavior for each of the three options

over the next couple days. Just a bit busy with the end of the semester approaching after all

[CosmicHorrorDev]

So I found time to go ahead and make the changes. I based the shell completions off the os flag since that seemed pretty similar, but I did not take the time to test any of them. And then I also went ahead and rebased the fix for the tar file being updated so that the whole testing suite could run, so everything should be ready for a review.

[CosmicHorrorDev]

Saw this got some merge conflicts over time so I decided to go ahead and fix them.

[dbrgn]

Saw this got some merge conflicts over time so I decided to go ahead and fix them.

Great, thanks, and sorry for the delay!

I applied rustfmt on the master branch, this should get rid of your first commit. There's also a conflict in Cargo.toml now (because of #93). Would you mind rebasing? (If you want, I can also do it for you and push to your branch.)

[CosmicHorrorDev]

I can fix it and rebase if you give me about a week (semester is busy atm). But if you don't mind doing it yourself and pushing the changes then feel free!

[dbrgn]

@LovecraftianHorror great, I went ahead and rebased your branch. I also squashed a few of the commits (e.g. the test fixes).

Will try to review (and ideally merge) the PR tonight.

[dbrgn]

Thanks @LovecraftianHorror, this looks great 🙂 I only fixed a small nitpick (didn't want to bother you with a change request), now it should be ready to merge if CI passes.

There's one more open PR, if I get that reviewed soon I should be able to create a new release next week.