As has been announced, DMD now has colorized syntax highlighting
in error messages:
http://forum.dlang.org/post/of9oao$230j$1 digitalmars.com
With 2.075's release near, now would be a good time to decide on
a nice color palette that looks fine on most terminals. So,
please vote:
https://github.com/dlang/dmd/pull/6943
Obligatory:
- Yes, not everyone likes colors. You can turn all colors off
with a command-line switch.
- Yes, everyone agrees that having all colors be configurable
would be good. We still need defaults that are going to look OK
on most terminals.
- Yes, no matter what colors we choose, they're going to look bad
on some terminal somewhere. Let's worry about the major
platforms' most common terminals for now.

As has been announced, DMD now has colorized syntax highlighting in
error messages:
http://forum.dlang.org/post/of9oao$230j$1 digitalmars.com
With 2.075's release near, now would be a good time to decide on a
nice color palette that looks fine on most terminals. So, please vote:
https://github.com/dlang/dmd/pull/6943
Obligatory:
- Yes, not everyone likes colors. You can turn all colors off with a
command-line switch.
- Yes, everyone agrees that having all colors be configurable would be
good. We still need defaults that are going to look OK on most
terminals.
- Yes, no matter what colors we choose, they're going to look bad on
some terminal somewhere. Let's worry about the major platforms' most
common terminals for now.

The cardinal rule of color selection: NEVER only set the foreground
color or the background color alone. ALWAYS set both, otherwise you will
get invisible text (or barely-visible text, like yellow on white) on
somebody's terminal, and they will be very, very angry.
T
--
Marketing: the art of convincing people to pay for what they didn't need before
which you fail to deliver after.

The cardinal rule of color selection: NEVER only set the
foreground color or the background color alone. ALWAYS set
both, otherwise you will get invisible text (or barely-visible
text, like yellow on white) on somebody's terminal, and they
will be very, very angry.

Nothing actually does that... so I don't think that's true. Maybe
on the web, but not in terminals.

The cardinal rule of color selection: NEVER only set the foreground
color or the background color alone. ALWAYS set both, otherwise you
will get invisible text (or barely-visible text, like yellow on
white) on somebody's terminal, and they will be very, very angry.

Nothing actually does that... so I don't think that's true. Maybe on
the web, but not in terminals.

I've seen complaints from people who have black-on-white terminals (or
vice versa) finding some programs producing unreadable text because the
program set the foreground color to black without also setting the
background. Of course, it's rare that programs would explicitly set
black or white foreground, but I happen to use a light green background
for my terminals and so a green foreground, for example, would be pretty
unreadable for me.
The point is that you can't predict what the default background color is
set to, so unless you set both, there will always be some case where it
looks bad or is outright unreadable.
T
--
What are you when you run out of Monet? Baroque.

I've seen complaints from people who have black-on-white
terminals (or vice versa) finding some programs producing
unreadable text because the program set the foreground color to
black without also setting the background. Of course, it's
rare that programs would explicitly set black or white
foreground, but I happen to use a light green background for my
terminals and so a green foreground, for example, would be
pretty unreadable for me.

Unless the program is a full-screen application, setting the
background color is the wrong solution. It will just make the
terminal look like a zebra, alternating contrast every time the
program's output starts and ends. I.e.: awful, which is why
nobody does this.

The point is that you can't predict what the default background
color is set to, so unless you set both, there will always be
some case where it looks bad or is outright unreadable.

This is why the screenshots I generated include both
dark-on-light and light-on-dark terminals. It is not impossible
to choose a color set that will look okay on both.

The cardinal rule of color selection: NEVER only set the
foreground color or the background color alone.

Fun fact: this is why terminal.d's api is `color(fg, bg)` instead
of foregroundColor and backgroundColor independently.
But, I actually hate it in terminals when individual lines have
different background colors, it doesn't really help legibility
since the surrounding clashing color continues to bleed the
contrast. That's why terminal.d now has Color.DEFAULT values and
I use that for the bg basically every time.
(Instead, as I've said a few times, I changed my terminal
*emulator*, yes the display side of it, to adjust the palette
based on what background is there. If you tell it to output color
0 on 0, it will actually do gray on black, despite 0 on 7 being
black on white. I figured the exact meaning of the palette
entries were less important than consistent legibility, and I'm
very happy with that. Now *any* program using *any* settings is
usable for me, including in sunlight, without excessive eye
strain. Big win.)

The cardinal rule of color selection: NEVER only set the foreground
color or the background color alone. ALWAYS set both, otherwise you will
get invisible text (or barely-visible text, like yellow on white) on
somebody's terminal, and they will be very, very angry.

Since an application cannot set any explicit colors, only symbolic names
for colors, and they're limited to 16. It's up to the theme of the
terminal emulator to make sure all colors look good on the chosen
background color.
--
/Jacob Carlborg

As has been announced, DMD now has colorized syntax
highlighting in error messages:
http://forum.dlang.org/post/of9oao$230j$1 digitalmars.com
With 2.075's release near, now would be a good time to decide
on a nice color palette that looks fine on most terminals. So,
please vote:
https://github.com/dlang/dmd/pull/6943
Obligatory:
- Yes, not everyone likes colors. You can turn all colors off
with a command-line switch.
- Yes, everyone agrees that having all colors be configurable
would be good. We still need defaults that are going to look OK
on most terminals.
- Yes, no matter what colors we choose, they're going to look
bad on some terminal somewhere. Let's worry about the major
platforms' most common terminals for now.

This will be a nightmare if you do not allow it to be
configurable! Hard coding anything is very bad when others are
will use it.
Make a default color scheme that works for the majority as you
are, but then allow it to be easily changed. E.g., it can read a
config file or passed through the command line(possibly different
color schemes can be selected). Do it right or suffer the
consequences!

This will be a nightmare if you do not allow it to be
configurable! Hard coding anything is very bad when others are
will use it.
Make a default color scheme that works for the majority as you
are, but then allow it to be easily changed. E.g., it can read
a config file or passed through the command line(possibly
different color schemes can be selected). Do it right or suffer
the consequences!

If you feel so strongly about this, please submit a PR!
Either way, -color=off has been there for a while.

- Yes, not everyone likes colors. You can turn all colors off
with a command-line switch.

Is there a way to do this globally? For example, a config file or
an environment variable?
I'm one of the rare people who use a light background in my
terminal (like 99% of websites). It seems only dark backgrounds
are considered, which is understandable.

Is there a way to do this globally? For example, a config file
or an environment variable?

I believe you can add -color=off to DFLAGS in sc.ini / dmd.conf.

It seems only dark backgrounds are considered, which is
understandable.

Not true. If you follow the link, you can see that one of the
tested terminals has a dark-on-light color scheme (macOS
Terminal.app). Unfortunately, even the "dark" colors look very
bright on Terminal.app. It's likely they will look better in your
terminal.

I'm one of the rare people who use a light background in my
terminal (like 99% of websites). It seems only dark backgrounds
are considered, which is understandable.

I also use light backgrounds... so I'm advocating for the light
bg people, but it is hard to actually win.
I think y'all should just use a better terminal emulator with a
sane palette. The OS X terminal does a better job than xterm at
least (and Cybershadow is testing on the osx terminal for the
light bg in the pictures on github), but the best solution is to
use a decent palette and adjust your greens and yellows and cyans
to be legible on white.
Still, the dmd default are trying to be usable on white as well.

With 2.075's release near, now would be a good time to decide
on a nice color palette that looks fine on most terminals. So,
please vote:

What ever you do, please don't use extreme high intensity colors
like red(255,0,0), green (0,255,0) or blue (0,0,255). They'll
burn through your eyes and look bad on either white or black.
If you replace 0s with 32 and 255s with 192 you'll get colors
that are more easy on the eyes and will work better on both black
and white backgrounds.
Another strategy is to use HSV.
Set saturation and value something decent like 80 and 75.
Then loop through hue with 360 / num_colors step + good offset.
Now you should get enough colors that are as far from each other
as they can be and give good contrast.
You can quickly preview this in some photo editor, or maybe even
faster by writing some d code :)
I guess the next level would be actual color design instead of
nerdy math.

What ever you do, please don't use extreme high intensity
colors like red(255,0,0), green (0,255,0) or blue (0,0,255).

That's up to the terminal (or your configuration of it). Without
making many assumptions, console applications are limited to 16
symbolic colors, with their exact values depending on the
OS/terminal/configuration.

What ever you do, please don't use extreme high intensity
colors like red(255,0,0), green (0,255,0) or blue (0,0,255).

That's up to the terminal (or your configuration of it).
Without making many assumptions, console applications are
limited to 16 symbolic colors, with their exact values
depending on the OS/terminal/configuration.

Right. I should've known that.
I guess I don't really use cmd prompt or bash much these days.
I'm pretty much always on windows and using Visual Studio for D,
C/C++ and others with custom color plugin for errors. And GUI
everywhere :).

As has been announced, DMD now has colorized syntax
highlighting in error messages:
http://forum.dlang.org/post/of9oao$230j$1 digitalmars.com
With 2.075's release near, now would be a good time to decide
on a nice color palette that looks fine on most terminals. So,
please vote:
https://github.com/dlang/dmd/pull/6943
Obligatory:
- Yes, not everyone likes colors. You can turn all colors off
with a command-line switch.
- Yes, everyone agrees that having all colors be configurable
would be good. We still need defaults that are going to look OK
on most terminals.
- Yes, no matter what colors we choose, they're going to look
bad on some terminal somewhere. Let's worry about the major
platforms' most common terminals for now.

As has been announced, DMD now has colorized syntax highlighting in
error messages:
http://forum.dlang.org/post/of9oao$230j$1 digitalmars.com
With 2.075's release near, now would be a good time to decide on a nice
color palette that looks fine on most terminals. So, please vote:
https://github.com/dlang/dmd/pull/6943
Obligatory:
- Yes, not everyone likes colors. You can turn all colors off with a
command-line switch.
- Yes, everyone agrees that having all colors be configurable would be
good. We still need defaults that are going to look OK on most terminals.
- Yes, no matter what colors we choose, they're going to look bad on
some terminal somewhere. Let's worry about the major platforms' most
common terminals for now.

I would argue pretty strongly that this should be toned down as much as
possible. All example schemes in the PR so far don't seem to add any
real readability value overall.
Spontaneously I'd suggest something like highlighting just keywords and
punctuation with a single different color and making the keywords also
bold. That would give the code snippets some structure, without letting
them fight for attention with error/warning colors or other code snippets.
Using a uniform dark gray background color for code could then solve two
issues: visually separating text from code and avoiding the problem with
differently configured default colors in the terminal.

I would argue pretty strongly that this should be toned down as
much as possible.

From the perspective of a personal preference, or an objective
analysis? It sounds like the former but isn't worded as one.

All example schemes in the PR so far don't seem to add any real
readability value overall.

Readability and aesthetics are distinct goals!

Using a uniform dark gray background color for code could then
solve two issues: visually separating text from code and
avoiding the problem with differently configured default colors
in the terminal.

Fairly sure painting parts of a line with a dark gray background
is not going to look great on an otherwise dark-on-light
terminal. The terminal excerpt blocks on dlang.org look kind of
jarring already: http://dlang.org/dmd-windows.html#library

I would argue pretty strongly that this should be toned down as much
as possible.

From the perspective of a personal preference, or an objective analysis?
It sounds like the former but isn't worded as one.

Intended to be more of the latter, especially as a consequence of the
readability concern. The typical colorful syntax highlighting that is
often used (lets say like the Monokai theme), starts to break down when
it isn't used within its own context. Instead it starts to fight for
attention with the error message and with the other colored text parts.
The result can then be a net loss in visual structure.
Apart from color, there are other possible means to fix this, for
example adding vertical spacing or delimiters between separate error
messages.

All example schemes in the PR so far don't seem to add any real
readability value overall.

Readability and aesthetics are distinct goals!

True, and IMO, the former is what should be our primary goal. When that
is reached, aesthetics can be optimized. But if we don't improve
readability with this, what's the point of this feature?

Using a uniform dark gray background color for code could then solve
two issues: visually separating text from code and avoiding the
problem with differently configured default colors in the terminal.

Fairly sure painting parts of a line with a dark gray background is not
going to look great on an otherwise dark-on-light terminal. The terminal
excerpt blocks on dlang.org look kind of jarring already:
http://dlang.org/dmd-windows.html#library

But surely better than a light gray or white on white. Otherwise the
whole text needs to have some kind of highly saturated color to avoid
such situations by default. Just ruling out a white background would be
a bad idea. I think on macOS that's the default, for example.

Intended to be more of the latter, especially as a consequence
of the readability concern. The typical colorful syntax
highlighting that is often used (lets say like the Monokai
theme), starts to break down when it isn't used within its own
context. Instead it starts to fight for attention with the
error message and with the other colored text parts. The result
can then be a net loss in visual structure.

Hmm, that may be true, but I'm not sure if it can be quantified.
Our only numbers are individuals' preferences, and so far this
change seems to be in the favor of many.

Apart from color, there are other possible means to fix this,
for example adding vertical spacing or delimiters between
separate error messages.

That will certainly be worth considering should we make more
error messages span multiple lines as clang does.

True, and IMO, the former is what should be our primary goal.
When that is reached, aesthetics can be optimized. But if we
don't improve readability with this, what's the point of this
feature?

I don't think readability isn't improved (unless you refer to the
original choice of colors, in which case I agree) :)

But surely better than a light gray or white on white.
Otherwise the whole text needs to have some kind of highly
saturated color to avoid such situations by default. Just
ruling out a white background would be a bad idea. I think on
macOS that's the default, for example.

I don't know where the repeated false impression that we're
ruling out white backgrounds is coming from in this thread, when
it can be dispelled with one click. I specifically test the
default color scheme of the default terminal application on macOS.

Intended to be more of the latter, especially as a consequence of the
readability concern. The typical colorful syntax highlighting that is
often used (lets say like the Monokai theme), starts to break down
when it isn't used within its own context. Instead it starts to fight
for attention with the error message and with the other colored text
parts. The result can then be a net loss in visual structure.

Hmm, that may be true, but I'm not sure if it can be quantified. Our
only numbers are individuals' preferences, and so far this change seems
to be in the favor of many.

I don't know, it probably could indeed be quantified in some way, but
maybe we don't have to go there. What we should at least do, however, is
to set up some rules that define the space in which the possible color
themes can be set up.
For example, not using the same or a similar color as one that is
already used to mark errors, warnings or deprecations would be such a
rule. Having normal text visually distinct would be another (i.e. not
using the terminal's default color within highlighted code). And of
course the usual rules, such as ensuring sufficient contrast between
background and foreground, and possibly not using colors that people
with a red/green blindness can't distinguish.
Interestingly, all of the examples in the PR fail at least one of those
rules (with the last one excluded).

Apart from color, there are other possible means to fix this, for
example adding vertical spacing or delimiters between separate error
messages.

That will certainly be worth considering should we make more error
messages span multiple lines as clang does.

True, and IMO, the former is what should be our primary goal. When
that is reached, aesthetics can be optimized. But if we don't improve
readability with this, what's the point of this feature?

I don't think readability isn't improved (unless you refer to the
original choice of colors, in which case I agree) :)

For example, With the suggestions that I made in the first post, I'd
argue that readability *is* improved. With a very colorful theme and no
background color that sets it apart from normal text, not sure if that
can still be the case. But there may be something in-between that works
(which I tried to generalize as "toned down").
Another idea would be using a single hue and different variations in
font weight and brightness, but that can quickly get difficult w.r.t
contrast for slightly tinted background colors, too.

But surely better than a light gray or white on white. Otherwise the
whole text needs to have some kind of highly saturated color to avoid
such situations by default. Just ruling out a white background would
be a bad idea. I think on macOS that's the default, for example.

I don't know where the repeated false impression that we're ruling out
white backgrounds is coming from in this thread, when it can be
dispelled with one click. I specifically test the default color scheme
of the default terminal application on macOS.

But it seems like the solution for that is to use saturated colors for
everything. There are also some examples that clearly don't work on a
white background, such as using cyan. Or examples in a black background,
such as using saturated blue.
If we really want to reduce this to a pure question of favorite color
themes, I'd propose to just take either Monokai or the Material UI
theme. In various places those seem to come up as the two most popular
themes, so using those is likely to be quite representative:
https://atom.io/themes/list?direction=desc&sort=stars

But it seems like the solution for that is to use saturated
colors for everything. There are also some examples that
clearly don't work on a white background, such as using cyan.
Or examples in a black background, such as using saturated blue.

As I've already mentioned, even the "dark" colors look very
bright on Terminal.app. I think the program's defaults are simply
bad. Within these constraints, I think it should be at least not
unusable.

If we really want to reduce this to a pure question of favorite
color themes, I'd propose to just take either Monokai or the
Material UI theme. In various places those seem to come up as
the two most popular themes, so using those is likely to be
quite representative:
https://atom.io/themes/list?direction=desc&sort=stars

I was specifically trying to steer away from a random
propose-and-comment approach, because I think we can do a lot better if
we first reduce the size of the design space using objective measures.
If we can agree to some extent that this makes sense, I can give it a go
and propose something concrete, too.

But it seems like the solution for that is to use saturated colors for
everything. There are also some examples that clearly don't work on a
white background, such as using cyan. Or examples in a black
background, such as using saturated blue.

As I've already mentioned, even the "dark" colors look very bright on
Terminal.app. I think the program's defaults are simply bad. Within
these constraints, I think it should be at least not unusable.

If the default goes from well readable but not highlighted to barely
readable in parts, then that would IMO be a pretty big failure. The
minimum goal should be to not make things worse overall on any of the
most common setups.

If we really want to reduce this to a pure question of favorite color
themes, I'd propose to just take either Monokai or the Material UI
theme. In various places those seem to come up as the two most popular
themes, so using those is likely to be quite representative:
https://atom.io/themes/list?direction=desc&sort=stars

I was specifically trying to steer away from a random
propose-and-comment approach, because I think we can do a lot
better if we first reduce the size of the design space using
objective measures. If we can agree to some extent that this
makes sense, I can give it a go and propose something concrete,
too.

Please do. I think your rules make sense, but it's difficult to
judge them without trying the task and finding out how well each
can be satisfied without making the task impossible.

If the default goes from well readable but not highlighted to
barely readable in parts, then that would IMO be a pretty big
failure. The minimum goal should be to not make things worse
overall on any of the most common setups.

That's a good point. Unfortunately, that leaves very few options.
If we are to stick to the tenets, we would need to remove nearly
all use of color, even from the "Error" and especially "Warning"
labels, as those are close to unreadable there.

I was specifically trying to steer away from a random
propose-and-comment approach, because I think we can do a lot better
if we first reduce the size of the design space using objective
measures. If we can agree to some extent that this makes sense, I can
give it a go and propose something concrete, too.

Please do. I think your rules make sense, but it's difficult to judge
them without trying the task and finding out how well each can be
satisfied without making the task impossible.

If the default goes from well readable but not highlighted to barely
readable in parts, then that would IMO be a pretty big failure. The
minimum goal should be to not make things worse overall on any of the
most common setups.

That's a good point. Unfortunately, that leaves very few options. If we
are to stick to the tenets, we would need to remove nearly all use of
color, even from the "Error" and especially "Warning" labels, as those
are close to unreadable there.

If they are only and consistently used for "Error" and "Warning", then
that's acceptable, because it's the color already unambiguously defines
the text. But in general I think that the possibilities are indeed very
limited if only the 16 base colors are allowed.

The question is how many users are actually ruled out by this.
Benefiting a large number of people at the expense of a few is a
reasonable approach in this case.

Sorry, I don't understand what you mean by this.

I mean if, by switching to more colors, we rule out few people, but are
able to provide a much better value for the (presumed) majority of
people with differently colored, but 256-color capable terminals, then
it may still be worth the trade-off (as long as those other terminals
don't get blown apart at least).

I mean if, by switching to more colors, we rule out few people,
but are able to provide a much better value for the (presumed)
majority of people with differently colored, but 256-color
capable terminals, then it may still be worth the trade-off (as
long as those other terminals don't get blown apart at least).

I mean if, by switching to more colors, we rule out few
people, but are able to provide a much better value for the
(presumed) majority of people with differently colored, but
256-color capable terminals, then it may still be worth the
trade-off (as long as those other terminals don't get blown
apart at least).

I mean if, by switching to more colors, we rule out few people, but
are able to provide a much better value for the (presumed) majority of
people with differently colored, but 256-color capable terminals, then
it may still be worth the trade-off (as long as those other terminals
don't get blown apart at least).

And Windows?

Good point, I forgot about that and it can definitely not be ignored. A
separate 16-color theme just on Windows, however, could still be an option.
I've posted a proposal with a very minimal use syntax coloring:
https://github.com/dlang/dmd/pull/6943#issuecomment-311514309
Given the 16 color constraint, there were actually only a handful of
other permutations that made sense and that I could think of, as long as
readability was the goal.

I mean if, by switching to more colors, we rule out few people,
but are able to provide a much better value for the (presumed)
majority of people with differently colored, but 256-color
capable terminals, then it may still be worth the trade-off (as
long as those other terminals don't get blown apart at least).

I suggest going a step further to true colors. It's supported by
at least [1]
- nearly all terminal emulators for Linux that can do 256 colors
(all libvte-based ones, e.g.)
- iterm2 and macterm for macOS
- mintty and Windows 10 bash console for Windows (10)
[1]
https://gist.github.com/XVilka/8346728#now-supporting-truecolour

As has been announced, DMD now has colorized syntax highlighting in error
messages:
http://forum.dlang.org/post/of9oao$230j$1 digitalmars.com
With 2.075's release near, now would be a good time to decide on a nice color
palette that looks fine on most terminals. So, please vote:
https://github.com/dlang/dmd/pull/6943

In the spirit of this, a lot of (rather tedious) work needs to be done on the
error messages themselves to enable color syntax highlighting. Specifically,
replacing ' ' with ` `, and adding ` ` around %s formats when code is being
emitted to the %s.
It's tedious because of all the messages in test/fail_compilation/* that need
updating.
It would also be helpful to pull things like:
https://github.com/dlang/dmd/pull/6890

- Yes, not everyone likes colors. You can turn all colors off
with a command-line switch.
- Yes, everyone agrees that having all colors be configurable
would be good. We still need defaults that are going to look OK
on most terminals.
- Yes, no matter what colors we choose, they're going to look
bad on some terminal somewhere. Let's worry about the major
platforms' most common terminals for now.

All of these points give added weight to this feature being opt
in, not opt out. Why would we want to make output worse? Also, we
shouldn't syntax highlight the message, just colour the whole
line.

As has been announced, DMD now has colorized syntax highlighting in
error messages:
http://forum.dlang.org/post/of9oao$230j$1 digitalmars.com
With 2.075's release near, now would be a good time to decide on a nice
color palette that looks fine on most terminals. So, please vote:

Hasn't DMD already been coloring error messages for about the past year?
Or is it DUB that's been doing that to DMD's output? Or are we talking
about something different then what was already there?

As has been announced, DMD now has colorized syntax highlighting in
error messages:
http://forum.dlang.org/post/of9oao$230j$1 digitalmars.com
With 2.075's release near, now would be a good time to decide on a
nice color palette that looks fine on most terminals. So, please vote:
https://github.com/dlang/dmd/pull/6943
Obligatory:
- Yes, not everyone likes colors. You can turn all colors off with a
command-line switch.
- Yes, everyone agrees that having all colors be configurable would be
good. We still need defaults that are going to look OK on most
terminals.
- Yes, no matter what colors we choose, they're going to look bad on
some terminal somewhere. Let's worry about the major platforms' most
common terminals for now.

The cardinal rule of color selection: NEVER only set the foreground
color or the background color alone. ALWAYS set both, otherwise you will
get invisible text (or barely-visible text, like yellow on white) on
somebody's terminal, and they will be very, very angry.
T
--
Marketing: the art of convincing people to pay for what they didn't need
before which you fail to deliver after.