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.

On Tue, Jun 27, 2017 at 02:32:28PM +0000, Vladimir Panteleev via Digitalmars-d wrote:
> 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.

On Tuesday, 27 June 2017 at 17:11:32 UTC, H. S. Teoh wrote:
> 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.

On Tue, Jun 27, 2017 at 05:24:46PM +0000, Vladimir Panteleev via Digitalmars-d wrote:
> On Tuesday, 27 June 2017 at 17:11:32 UTC, H. S. Teoh wrote:
> > 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.

On Tuesday, 27 June 2017 at 14:32:28 UTC, Vladimir Panteleev wrote:
> 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!

On Tuesday, 27 June 2017 at 17:32:23 UTC, FoxyBrown wrote:
> 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.

On Tuesday, 27 June 2017 at 14:32:28 UTC, Vladimir Panteleev wrote:
> - 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.

On Tuesday, 27 June 2017 at 17:28:42 UTC, H. S. Teoh wrote:
> 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.

On Tuesday, 27 June 2017 at 17:41:35 UTC, qznc wrote:
> 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.

On Tuesday, 27 June 2017 at 14:32:28 UTC, Vladimir Panteleev wrote:
> 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.