Stop using bold text for input and answers #11250

jayschwa · 2015-05-12T20:39:29Z

This pull request turns off bold text everywhere and changes it to "normal" text.

Julia should respect the user's font settings; if they really wanted to see bold text everywhere, they presumably would have adjusted it in their terminal's settings. I don't think there's a compelling reason for Julia not to toe the line here. For the existing Julia users who like the good old days, bold text can still be enabled via the JULIA_[INPUT|ANSWER]_COLOR=bold environment variables.

Bold styling should be used conservatively to highlight information. Switching the baseline to normal text opens the door for more intelligent use of bold in the future. 🚀

StefanKarpinski · 2015-05-12T20:47:24Z

Normal printed output is non-bold. I find that the difference helps make it clearer what's going on. We already make colored responses opt-in. At this rate, we're headed towards the git situation where 99% of users don't know how to make it look colorful or nice.

andreasnoack · 2015-05-12T20:53:41Z

+1. I've had this locally for a while. I agree that bold should only be used for emphasizing pieces of text.

ssfrr · 2015-05-17T05:01:55Z

This would also resolve #8096 (colors would show up correctly for people using the Solarized colorscheme). Note that (as I mention in that issue) I think that this is basically Solarized's fault for changing the meaning of bold text, but it is a relatively popular theme, and it seems weird to use bold unnecessarily.

@StefanKarpinski isn't the color by itself enough to differentiate from normal printed text? Maybe colored text could print in non-bold color and if color is turned off all colored text just gets bolded instead?

andreasnoack · 2015-11-03T01:01:47Z

I just got annoyed by the bold fonts again. It really makes the text harder to read and I agree with @jayschwa that it is wrong to use bold here so I'm in favor of merging this.

jayschwa · 2015-11-03T01:36:58Z

Rebased from master and resolved merge conflict.

andreasnoack · 2015-11-03T11:57:36Z

@jayschwa Thanks. I'll merge tomorrow unless someone objects.

blakejohnson · 2015-11-03T18:47:04Z

@andreasnoack I didn't sense a consensus on this one, yet.

hayd · 2015-11-03T19:27:39Z

Being able to disambiguate at the repl:

f() = println("\"hello\"")
g() = "hello"

seems useful. I don't care about julia> INPUT but output should be emphasized.

andreasnoack · 2015-11-03T20:09:04Z

I agree that it should be possible to disambiguate f and g in your example, but I don't think bold is the right choice. IPython, R and Matlab print Out[_x_], [_linenumber_] and ans = respectively before output. We could consider printing something similar or alternatively we could use a different color for output.

musm · 2015-11-03T21:29:29Z

Is it possible to enable bold (or a color) on windows, or is this a linux only feature? I don't have anything bolded.

jayschwa · 2015-11-04T01:43:07Z

@mmoh, Julia on Windows uses non-bold text by default. Bold doesn't appear to do much in a Windows terminal. It brightens the color a bit, but doesn't change the visual weight of the characters. Here's how to play with it:

print_with_color(:bold, "This is bold")

tkelman · 2015-11-04T03:58:18Z

I think it should work in mintty though

andreasnoack · 2015-11-04T13:54:48Z

@jayschwa Do you have a proposal for distinguishing the return from a function from what is written to STDOUT?

jayschwa · 2015-11-04T16:23:39Z

Is JULIA_ANSWER_COLOR not sufficient?

andreasnoack · 2015-11-04T17:19:44Z

I think we should set a default value. :cyan or :magenta would be fine with me.

jayschwa · 2015-11-04T17:57:56Z

Using a prefix seems more in line with what other language REPLs do, but I feel like that falls outside the scope of this PR. I personally can't recall many times where differentiating between a return value and stdout was problematic for me.

StefanKarpinski · 2015-11-06T18:00:22Z

I have return values as :magenta which looks quite nice. May even look ok on Windows. IIRC, cyan was bad on Windows.

andreasnoack · 2015-11-09T15:17:06Z

Let's try with default output in magenta. Then I think we have a compromise that will eliminate the bold letters and still disambiguate printed output from return values. @jayschwa, if you update then I'll merge.

jakebolewski · 2015-11-09T15:17:49Z

NO!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

jayschwa · 2015-11-09T15:38:44Z

NO!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

I concur, I think magenta will be more offensive to my eyes than bold 🙈

I'm skeptical that there is widespread confusion between prints and REPL output. JULIA_ANSWER_COLOR is available for those who want to tweak it.

andreasnoack · 2015-11-09T15:49:52Z

@StefanKarpinski Color seems to be a sensitive issue. Should we try without and see if it causes confusion that return values in the REPL and printed output are identical? I like the magenta output idea, but my main priority is to get rid of the bold letters.

StefanKarpinski · 2015-11-09T19:20:37Z

Apparently the worst bikeshed is the original: what color to paint the bike shed.

StefanKarpinski · 2015-11-09T19:22:59Z

I worry that this now defaults to giving people the least information and the least "fancy" setup. This is kind of like how git defaults to not using colors. As a result, I've seen people who've used git for years with no colors. I turn the option on for them and suddenly the whole experience is changed. I don't want Julia to end up like this. Even if you don't like the default output, at least the use of colors and bold lets you know that colors and bold are an option and something that you can configure.

jakebolewski · 2015-11-09T19:38:20Z

Why does bold == fancy? It seems like a subjective opinion. I don't like that you take away bold as an option to emphasize particular output. So it seems like you can add more information to output when bold by default is turned off.

hayd · 2015-11-09T19:47:00Z

If it's easy and well documented to turn off the bold, what's the problem?

I'm not sure magenta is a good choice either.

jayschwa · 2015-11-09T20:29:15Z

If it's easy and well documented to turn off the bold, what's the problem?

The problem is outlined in the original post. Matching the terminal's font shouldn't require explicit action, it should happen by default.

jayschwa · 2017-01-07T05:44:08Z

I have rebased the PR off master and replaced some hardcoded ANSI codes with text_colors.

@KristofferC, I did not remove the bold from input_color() and answer_color(). As far as I can tell, they don't actually affect anything. Might be worth investigating!

[Updated]

After playing, I see that input_color() and answer_color() are engaged when one of the JULIA_*_COLOR environment variables is set. Since the hardcoded default is now :normal, it's blowing away the :bold in the function. Anyhow, I'm going to remove the :bold from those functions as well.

JeffBezanson · 2017-01-07T06:14:29Z

👍

KristofferC · 2017-01-07T09:36:31Z

base/REPL.jl

@@ -958,7 +956,7 @@ type StreamREPL <: AbstractREPL
    waserror::Bool
    StreamREPL(stream,pc,ic,ac) = new(stream,pc,ic,ac,false)
 end
-StreamREPL(stream::IO) = StreamREPL(stream, julia_green, Base.input_color(), Base.answer_color())
+StreamREPL(stream::IO) = StreamREPL(stream, Base.text_color[:green], Base.input_color(), Base.answer_color())


This should probably be light_green if we want to keep the same color as before.

it should also be text_colors, which tells me this line isn't hit by tests at all

When is this even used?

remote repl maybe? untested stuff that probably only Keno uses?

Re-pushed with the typo fixed. :green was left as-is because that matches what it was before. The only difference is that it no longer contains the code for bold, but it was redundant since bold is prefixed later on by Prompt. The effect remains the same: bold, green julia>.

No, because on most terminals (urxvt, gnome-terminal, cmd etc) bold makes text bold AND also makes the color brighter (the light versions of the color).

The purpose here is to strip the bold part and not change the color, hence it should be :light_green.

The bold is still being applied, just somewhere else, so the color isn't actually changing (nor the bold). I see what you mean though, so I will updated it. It probably makes sense to do the same in the banner too, right?

Oh, if the boldness is still being applied then it doesn't really matter. I remember now that I had to add that here: https://github.com/JuliaLang/julia/pull/18628/files#diff-8dc8200a114faecb709b7b96e96fc0cfR632. Maybe change to light_green and remove that bold part so the prompt is not in bold?

I'm going to leave the prompts bold. Changing the color to light_green still might make sense because it decouples the color from its boldness. However, do the light variants work reliably across platforms?

Everywhere I have tested, yes. Errors are currently being printed in light_red for example.

KristofferC · 2017-01-07T16:10:57Z

This needs a NEWS entry preferably with a link to the manual how to change (and get back the bold) for the input / ouput color.

jayschwa · 2017-01-07T20:46:02Z

Pushed an update that contains a NEWS entry for the style change.

Some hardcoded ANSI codes were also replaced with `text_colors`.

jayschwa · 2017-01-07T21:43:20Z

@KristofferC, I just updated the prompt and banner colors to use light variants. In the future, if bold is turned off on any of these things, their color will be unaffected. Dots in the banner are still bold, but I did unbold the ASCII art "julia" part since I think it looks better.

Are there any Windows builds that are automatically generated? I'm interested to see how light variants work there (but don't let that hold up the PR from being merged).

KristofferC · 2017-01-07T21:58:15Z

Can't you just print some hard coded ANSI to see how it looks on windows? With everything else being not bold I don't see a reason for having the prompt bold but I don't mind that much.

JeffBezanson · 2017-01-08T06:09:29Z

Non-bold green is pretty dark in some terminals.

KristofferC · 2017-01-08T07:17:48Z

Yes but see discussion at #11250 (comment)

jayschwa · 2017-01-08T07:50:01Z

I just played with a nightly on Windows and convinced myself that light_[color] is working and equivalent to bold [color]. I think it's good to go.

With everything else being not bold I don't see a reason for having the prompt bold

This PR has been lingering for a year and a half. I'd rather not increase the scope 😄.

KristofferC · 2017-01-08T12:02:45Z

Ok, I'll make that PR then ;)

StefanKarpinski · 2017-01-24T01:25:55Z

What is the status of this? It seems to have stalled out again, although the only conflict is NEWS.md

jayschwa · 2017-01-25T00:06:59Z

I resolved the conflict in NEWS, which was caused by all of the entries being wrapped to a different line length on master. I suggest using "Display the rich diff" when reviewing that file.

tkelman · 2017-01-25T00:43:10Z

NEWS.md

+    For example, one way of doing this is adding `ENV["JULIA_INPUT_COLOR"] = :bold` and `ENV["JULIA_ANSWER_COLOR"] = :bold` to the `.juliarc.jl` file.
+    See the [manual section on customizing colors](http://docs.julialang.org/en/latest/manual/interacting-with-julia/#customizing-colors) for more information.
+
+  * The default color for info messages has been changed from blue to cyan, and for warning messages from red to yellow.


this should probably have its issue/pr reference added, it got lost at some point

musm · 2017-04-18T17:38:53Z

It looks like all the underscore light_ colors ended up breaking the julia repl color setup for me on 0.6 on the bash subsystem for windows.

E.g. on 0.5

E.g. on 0.6

Is it possible to remove the light_ prefix so that things work as before ? I imagine I will not be the only one experiencing this issue.

KristofferC · 2017-04-18T17:42:10Z

Yes, that should work fine.

musm · 2017-04-18T17:43:37Z

thanks @KristofferC mind submitting a PR or should I?

KristofferC · 2017-04-18T17:45:27Z

Likely to happen faster if you do it.

ViralBShah added the REPL Julia's REPL (Read Eval Print Loop) label May 17, 2015

jayschwa force-pushed the the-goggles-do-nothing branch from 9850d29 to c5105e7 Compare November 3, 2015 01:34

jayschwa force-pushed the the-goggles-do-nothing branch from c5105e7 to 6827085 Compare November 3, 2015 01:39

nalimilan mentioned this pull request Nov 4, 2015

prettier show function JuliaData/DataFrames.jl#881

Closed

jayschwa force-pushed the the-goggles-do-nothing branch from d054781 to 8c490d6 Compare January 7, 2017 05:34

jayschwa changed the title ~~Stop using bold text everywhere~~ Stop using bold text for input and answers Jan 7, 2017

jayschwa force-pushed the the-goggles-do-nothing branch 2 times, most recently from 16d346e to 20d7a86 Compare January 7, 2017 06:01

KristofferC reviewed Jan 7, 2017

View reviewed changes

jayschwa force-pushed the the-goggles-do-nothing branch from 20d7a86 to 79d03c4 Compare January 7, 2017 20:43

jayschwa force-pushed the the-goggles-do-nothing branch from 79d03c4 to c5d8e55 Compare January 7, 2017 20:52

Stop using bold text for input and answers

e5ed283

Some hardcoded ANSI codes were also replaced with `text_colors`.

jayschwa force-pushed the the-goggles-do-nothing branch from c5d8e55 to e5ed283 Compare January 7, 2017 21:39

Merge branch 'master' into the-goggles-do-nothing

01c0fbf

tkelman reviewed Jan 25, 2017

View reviewed changes

StefanKarpinski merged commit 001a164 into JuliaLang:master Jan 25, 2017

jayschwa deleted the the-goggles-do-nothing branch January 25, 2017 16:39

musm mentioned this pull request Apr 18, 2017

Do not use light version of colors by default #21433

Merged

Stop using bold text for input and answers #11250

Stop using bold text for input and answers #11250

Conversation

jayschwa commented May 12, 2015

StefanKarpinski commented May 12, 2015

andreasnoack commented May 12, 2015

ssfrr commented May 17, 2015

andreasnoack commented Nov 3, 2015

jayschwa commented Nov 3, 2015

andreasnoack commented Nov 3, 2015

blakejohnson commented Nov 3, 2015

hayd commented Nov 3, 2015

andreasnoack commented Nov 3, 2015

musm commented Nov 3, 2015

jayschwa commented Nov 4, 2015

tkelman commented Nov 4, 2015

andreasnoack commented Nov 4, 2015

jayschwa commented Nov 4, 2015

andreasnoack commented Nov 4, 2015

jayschwa commented Nov 4, 2015

StefanKarpinski commented Nov 6, 2015

andreasnoack commented Nov 9, 2015

jakebolewski commented Nov 9, 2015

jayschwa commented Nov 9, 2015

andreasnoack commented Nov 9, 2015

StefanKarpinski commented Nov 9, 2015

StefanKarpinski commented Nov 9, 2015

jakebolewski commented Nov 9, 2015

hayd commented Nov 9, 2015

jayschwa commented Nov 9, 2015

jayschwa commented Jan 7, 2017 • edited Loading

JeffBezanson commented Jan 7, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jayschwa Jan 7, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

KristofferC Jan 7, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

KristofferC commented Jan 7, 2017 • edited Loading

jayschwa commented Jan 7, 2017

jayschwa commented Jan 7, 2017 • edited Loading

KristofferC commented Jan 7, 2017

JeffBezanson commented Jan 8, 2017

KristofferC commented Jan 8, 2017

jayschwa commented Jan 8, 2017 • edited Loading

KristofferC commented Jan 8, 2017

StefanKarpinski commented Jan 24, 2017

jayschwa commented Jan 25, 2017

Choose a reason for hiding this comment

musm commented Apr 18, 2017

KristofferC commented Apr 18, 2017

musm commented Apr 18, 2017

KristofferC commented Apr 18, 2017

jayschwa commented Jan 7, 2017 •

edited

Loading

jayschwa Jan 7, 2017 •

edited

Loading

KristofferC Jan 7, 2017 •

edited

Loading

KristofferC commented Jan 7, 2017 •

edited

Loading

jayschwa commented Jan 7, 2017 •

edited

Loading

jayschwa commented Jan 8, 2017 •

edited

Loading