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

Change default warn color to yellow #18453

Merged
merged 8 commits into from
Dec 17, 2016
Merged

Change default warn color to yellow #18453

merged 8 commits into from
Dec 17, 2016

Conversation

KristofferC
Copy link
Sponsor Member

@KristofferC KristofferC commented Sep 12, 2016

Change the warning color to what I believe is a better default (to yellow from red).

Reasons

  • Red is a bit harsh for a warning.
  • Googling around for warning messages it seems that the vast majority uses yellow for warnings. Following what appears to be a standard makes sense.
  • Having a visual difference between warnings and errors seems sensible.

xterm default
image

gnome-terminal default (ubuntu default)
image

gnome-terminal white background (this one is not so nice...)
image

powershell
image

win cmd
image

cc @twadleigh

@tkelman
Copy link
Contributor

tkelman commented Sep 12, 2016

guess the only question is why was it set to red from the beginning?

@KristofferC
Copy link
Sponsor Member Author

KristofferC commented Sep 12, 2016

Hah! Found it 68f63db#diff-2b2ebeef35e91b1fff15d49dc1d526b5R50. It got changed from yellow to red 3 ½ years ago.

@StefanKarpinski didn't like the yellow. Apparently it was red for a while then yellow then red again... lol

@ViralBShah
Copy link
Member

Yes, Red for errors, yellow for warning goes nicely with traffic light colors.

@nalimilan
Copy link
Member

Definitely a good idea to differentiate warnings from errors. I've had students who thought (in R) that a package wasn't installed correctly just because an innocent warning was printed in red.

@TotalVerb
Copy link
Contributor

To make everyone happy, can we use 256-colour orange if it's available, and fall back to yellow otherwise? Or is this possibly infeasible for portability?

@StefanKarpinski
Copy link
Sponsor Member

I don't really have an issue with yellow for warnings. This is why we really should ship our own terminal of some kind on Windows. On UNIX we're always going to need to deal with people's terminals, but xterm-265 should be possible on most UNIX systems.

@DNF2
Copy link

DNF2 commented Sep 13, 2016

My impression is that most hardcore SW developers use dark terminal/editor backgrounds. But I hope you will at least give some consideration to users who prefer light backgrounds. Yellow on white (and also cyan on white) are not great combinations. I certainly understand that it is hard, bordering on impossible, to choose colours that look good for both light and dark backgrounds.

I also have a (non-empirical, gut-level) hunch that people who use light backgrounds are less likely to tweak their setup.

@KristofferC
Copy link
Sponsor Member Author

Yellow on white is not so bad. The problem is that we are printing everything in bold all the time:

image

@ViralBShah
Copy link
Member

The solution to the white terminal is to have two profiles - light and dark and make it easy to switch.

@DNF2
Copy link

DNF2 commented Sep 13, 2016

Actually, I see that bold yellow looks ok for me, but the gnome-terminal version was bad. And honestly, I don't really think the colour below is yellow, it's more like beige.

screen shot 2016-09-13 at 09 53 05

@KristofferC
Copy link
Sponsor Member Author

Well, it is defined to be yellow at least.. http://pueblo.sourceforge.net/doc/manual/ansi_color_codes.html

@KristofferC
Copy link
Sponsor Member Author

In version 2.50 and later, bold is interpreted as ‘high-intensity’, which was the original ANSI definition. (High-intensity colors are brighter than low-intensity ones, which are the default.)

I guess some terminals does that which is why the bold yellow looks so bad on white.

@KristofferC
Copy link
Sponsor Member Author

KristofferC commented Sep 13, 2016

@TotalVerb AFAIU, detecting if a terminal supports 256 colors is tricky because terminals lie through their teeth. I can however give you #18473 so you can easily set orange yourself.

@ViralBShah
Copy link
Member

I kinda prefer orange over yellow.

@KristofferC
Copy link
Sponsor Member Author

And after #18473 you can easily set that with an env var. What we are talking about here is the default color and for that orange is out of the question due to not being supported in many default / unconfigured terminals.

@KristofferC
Copy link
Sponsor Member Author

Added news entry, anyone opposed of merging?

@kshyatt
Copy link
Contributor

kshyatt commented Sep 21, 2016

Bump.

@KristofferC
Copy link
Sponsor Member Author

From the 9 thumbs up, 0 thumbs down and the triviality of reverting, I will merge this at the end of the weekend if no one has objections.

@tkelman
Copy link
Contributor

tkelman commented Oct 8, 2016

That yellow will be pretty bad on light terminals. Is determining the background color any more doable than detecting 256 color support? We could also do yellow on Windows and orange elsewhere since I get the impression far fewer people use light background terminals on Windows, and it's the only place where 256 color support isn't a safe assumption.

@KristofferC
Copy link
Sponsor Member Author

Guess I will focus on the non boldness in the colorized messages then which is what is causing this to look bad on white backgrounds.

@KristofferC
Copy link
Sponsor Member Author

Rebased + hooked up pkg + test to use the warn color function.

I tried the online merge resolution tool and it sort of messed up my branch... Anyway the total diff of these commit seems ok so should be fine to squash.

Copy link
Contributor

@tkelman tkelman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so now this prints the lead "WARNING" in bold but the rest of the content not bold, right?

@@ -140,7 +140,7 @@ type Broken <: Result
orig_expr
end
function Base.show(io::IO, t::Broken)
print_with_color(:yellow, io, "Test Broken\n"; bold = true)
print_with_color(:Base.warn_color(), io, "Test Broken\n"; bold = true)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the : meant to be prefixed to Base here, or just a typo?

Copy link
Sponsor Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo (which I thought I fixed but maybe I forgot to commit the file).

@KristofferC
Copy link
Sponsor Member Author

Yes @tkelman.

@tkelman tkelman merged commit 363ecad into master Dec 17, 2016
@tkelman tkelman deleted the kc/warn_color branch December 17, 2016 06:45
@@ -60,9 +60,9 @@ Library improvements
Therefore, light versions of the colors are now supported.
For the available colors see the help entry on `print_with_color`.

* The default color for info messages has been changed from blue to cyan ([#18442]).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we should put this link back (and add 18453 too)

@tkelman tkelman added the needs news A NEWS entry is required for this change label Dec 31, 2016
@Sacha0 Sacha0 removed the needs news A NEWS entry is required for this change label May 12, 2017
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

10 participants