Skip to content

Redefine .noColor field of Color, NO_COLOR won't affect at runtime#267

Open
SourLemonJuice wants to merge 3 commits into
fatih:mainfrom
SourLemonJuice:main
Open

Redefine .noColor field of Color, NO_COLOR won't affect at runtime#267
SourLemonJuice wants to merge 3 commits into
fatih:mainfrom
SourLemonJuice:main

Conversation

@SourLemonJuice

@SourLemonJuice SourLemonJuice commented Sep 29, 2025

Copy link
Copy Markdown

Redefine the ".noColor *bool" field to ".isNoColor bool" of type "Color", this removed the pointless pointer and reduced the complexity.
Which also removed the boolPtr() method(?)

The test "TestNoColor_Env" now removed, because the NO_COLOR env should not affect at runtime.

In my software, I want to force output through HTTP with color(client is curl), but each time New() will always use NO_COLOR env without any judgment, #71 can't work.
In the previous code, New() even will ignore the global NoColor status. This is confusion caused by the function's naming.

Redefine the ".noColor *bool" field to ".useColor bool" of type "Color",
this removed the pointless pointer and reduced the complexity.
Which also removed the boolPtr() method(?)

The test "TestNoColor_Env" now removed, because the NO_COLOR env should
not affect at runtime.
SourLemonJuice added a commit to SourLemonJuice/ipapi-agent that referenced this pull request Sep 29, 2025
Replace fatih/color with my fork version, which fixes the force color
output issue. PR: fatih/color#267
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.

1 participant