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

Warning messages are printed with colors that are invisible on white background #4047

Closed
brianhuffman opened this issue May 30, 2018 · 11 comments

Comments

@brianhuffman
Copy link

Here's an example of a warning message that I received from a recent run of stack build:

Warning: addDependentFile path (Template Haskell) listed in
         /Users/huffman/Work/saw-script/deps/cryptol/.stack-work/dist/x86_64-osx/Cabal-2.0.1.0/build/src/Cryptol/Prelude.dump-hi
         does not exist: lib/Cryptol/Extras.cry

The problem is that on my terminal, which uses the default black-text-on-white-background theme, it looks like this:

stack-warning

The filenames are printed in a completely invisible bold white, and the word "Warning" is printed in a yellow color that is just barely visible against a white background. The text is only readable after highlighting it with the mouse.

To reproduce: Using a terminal with a dark-text-on-light-background theme, run any stack command that prints any kind of warning message.

Here is the output of stack --version:

Version 1.7.1, Git revision 681c800873816c022739ca7ed14755e85a579565 (5807 commits) x86_64 hpack-0.28.2
@brianhuffman
Copy link
Author

brianhuffman commented May 30, 2018

The offending lines in the source code are https://github.com/commercialhaskell/stack/blob/master/src/Stack/PrettyPrint.hs#L167

styleWarning :: AnsiDoc -> AnsiDoc
styleWarning = yellow

and https://github.com/commercialhaskell/stack/blob/master/src/Stack/PrettyPrint.hs#L181

styleFile :: AnsiDoc -> AnsiDoc
styleFile = bold . white

Looking at the source, I see that styleCurrent also uses the nearly-invisible yellow. I don't know if I've come across any messages printed with styleCurrent in practice, but maybe this color should be reconsidered as well.

@mattaudesse
Copy link
Member

Thanks @brianhuffman - that's definitely aggravating.

It's not a full solution, but are you aware of the --color never option?

It looks like you're using macOS. Are you running the standard terminal or something else (e.g. iterm2)?

@brianhuffman
Copy link
Author

Yes, I'm on MacOS, and I usually use iterm2.

@mgsloan mgsloan added this to the Support milestone Jun 11, 2018
@mgsloan
Copy link
Contributor

mgsloan commented Jun 11, 2018

The actual colors chosen are determined by your terminal, so I do not think that this is something that needs to be addressed in stack.

@mgsloan mgsloan closed this as completed Jun 11, 2018
@brianhuffman
Copy link
Author

@mgsloan Are you suggesting that I should remap the color "white" in my terminal to something dark?

@mgsloan
Copy link
Contributor

mgsloan commented Jun 11, 2018

Or remap the yellow to a darker shade. CLI apps are going to be using these colors, so they should be configured to be readable, if you want them to be readable.

@brianhuffman
Copy link
Author

I can deal with the yellow. The white-on-white is more of a problem. iTerm2 is configurable enough so that there are some workarounds for it (I found a "minimum contrast" setting) but for MacOS Terminal there aren't really any good options, short of redefining ANSI "white" to something that isn't white, or switching to a darker background color that is also visibly distinct from any other ANSI color. (Many of us who prefer white-background terminals do so because it matches the brightness level of all the other light-color-themed windows on our display, of which there are many on MacOS.)

Imagine if a command-line tool that you use had been designed (by white-background-terminal-using developers) to output text in ANSI black?

I propose that styleFile be redefined from bold . white to the following:

styleFile :: AnsiDoc -> AnsiDoc
styleFile = bold

This should provide the desired visible emphasis no matter what terminal color scheme is in use.

@mgsloan
Copy link
Contributor

mgsloan commented Jun 11, 2018

Oh, yes, I see. Yes, it makes sense to change that. One possible solution might be to set the background color dark for files. Alternatively, picking another color. I quite like how it currently looks, though.

@brianhuffman
Copy link
Author

I would be perfectly happy if the white text was also shown with a specified background color (e.g. black).

@mgsloan
Copy link
Contributor

mgsloan commented Jun 11, 2018

@brianhuffman I believe that this PR will resolve the issue #4079

mgsloan added a commit that referenced this issue Jun 14, 2018
Prettyprinting colors should also have a background that contrasts #4047
@snoyberg
Copy link
Contributor

Closing, since this appears to have been addressed by #4079.

mpilgrem added a commit to mpilgrem/stack that referenced this issue Jul 31, 2018
In order to ensure sufficient contrast on both black (dull black) and white (vivid white) terminals, also changes foreground text `bold . white` to `dullcyan` (affecting `styleFile` and `styleUrl`) and `yellow` to `dullyellow` (affecting `styleWarning` and `styleCurrent`).

`dullcyan` is used in preference to `black` (vivid black) because the latter is problematic with the solarised dark theme.

See also issue commercialhaskell#4047 and (reverted) commercialhaskell#4814.
mpilgrem added a commit to mpilgrem/stack that referenced this issue Aug 4, 2018
In order to ensure sufficient contrast on both black (dull black) and white (vivid white) terminals, also changes foreground text `bold . white` to `dullcyan` (affecting `styleFile` and `styleUrl`) and `yellow` to `dullyellow` (affecting `styleWarning` and `styleCurrent`).

`dullcyan` is used in preference to `black` (vivid black) because the latter is problematic with the solarised dark theme.

See also issue commercialhaskell#4047 and (reverted) commercialhaskell#4814.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants