Do not output colors e.g. into a pipe, unless forced. #1077
Conversation
Use the de-factoish environment variables CLICOLOR(_FORCE) to override default color behavior.
lanurmi
force-pushed
the
no-colors-on-non-tty
branch
from
9921fc6
to
ba34e3e
Compare
|
No windows option? |
|
windows already does not put color information into the I/O stream, it has this special API to put the console in a certain color mode. It just works very differently.. So I don't think this really needs a windows option.. |
|
Yea, I understand that part (about putting color information in the stream). I was just thinking more about keeping things consistent between platforms. If I have CLICOLOR=0 in my linux environment, I would like to see the same thing happen (interactively) when I set the environment variable in windows. The functions for retrieving environment variables and testing for tty are available on windows too. |
Colors probably cannot be forced on though, because of different implementation on Windows.
|
I added support for Windows too, as much as it can be supported due to the different way it works. I can squash the two commits into one, if desired. |
| static int shouldUseColors() { | ||
| // CLICOLOR* documented at: http://bixense.com/clicolors/ | ||
| return ((getenvOrFallback("CLICOLOR", "1")[0] != '0') && canUseColors()) | ||
| || getenvOrFallback("CLICOLOR_FORCE", "0")[0] != '0'; |
There was a problem hiding this comment.
I feel like, given the code below, that this function could be called a LOT...
Like, it appears to do this work every time you wanna change colour, is that right?
Can't this just be executed once at startup?
There was a problem hiding this comment.
I doubt it's of big impact... we don't set colors that often... only for errors, which are fatal generally, so it's a one time event...
I do agree that we could at startup however.. if @lanurmi has the time to do that, that would be great? but if not, I don't want to hold off for too long and let this PR sit around.
There was a problem hiding this comment.
Yeah, give him a few days, and if not... just merge ;)
There was a problem hiding this comment.
As long as premake doesn't color each character in regular output with a different color, is there a scenario where term_doSetTextColor() would be called a lot in the first place? What does one need to do wrong to get hundreds or thousands of colored lines (i.e. warnings or errors) currently?
I can make it cache the result, sure, but it adds some complexity, and we don't even know if shouldUseColors() is a hotspot in profiling.
There was a problem hiding this comment.
is there a scenario where
term_doSetTextColor()would be called a lot in the first place?
The unit tests now do this, sorry! It will be called 8200+ times when running the unit tests now, so it might be a good idea to cache the result. Additionally, Premake core might not call it a lot in regular usage, but that doesn't mean that modules can't call it a lot for any number of reasons.
There was a problem hiding this comment.
Lets merge it, and I'll take care of the caching...
Use the de-factoish environment variables CLICOLOR(_FORCE) to override default color behavior.