Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(stream): Support env-based auto-detection #72

Merged
merged 8 commits into from Mar 13, 2023
Merged

feat(stream): Support env-based auto-detection #72

merged 8 commits into from Mar 13, 2023

Conversation

epage
Copy link
Collaborator

@epage epage commented Mar 13, 2023

This supports

I had originally wanted to leave this to the application but it is a pain to deal with

  • anstyle_stream::stdout and astyle_stream::print become worthless
  • We could let apps do it through the global but correctly avoiding wincon breaks this

supports-color takes a different approach:

  • COLORTERM: since we aren't dealing with truecolor vs 256 vs 16, this mostly isn't needed
  • We are more permissive in assuming 16 color support for TERM
  • We don't auto-enable for CI
  • We don't check FORCE_COLOR which isn't really a documented standard in any way
    • This is derived from the node version which uses it to read the level of support (none, 16 color, 256 color, truecolor)
      • ansis compares different JS libs and whether they support it
    • rich supports checking the presence of it in Force color Textualize/rich#2449 (which means it'll do the wrong thing on 0)

Some things I disagree with supports-color

  • CLICOLOR_FORCE disallows truecolor (which isn't as relevant for us)
  • CLICOLOR=0 does not disable color support despite the definition being "Don’t output ANSI color escape codes"

I wish there was a way for us to detect if we are being piped to less -r.

@epage epage merged commit 0ada0d3 into main Mar 13, 2023
15 checks passed
@epage epage deleted the auto branch March 13, 2023 21:36
epage added a commit that referenced this pull request Mar 13, 2023
This is a follow up to #72

CI is a common enough of a piped target that supports ANSI escape codes
for us to treat it like `TERM` detection, I hope.  We'll see how
feedback works out on this.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant