On Tuesday, 27 June 2017 at 18:41:00 UTC, Random D user wrote:
> 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.

On Tuesday, 27 June 2017 at 18:42:45 UTC, Vladimir Panteleev wrote:
> On Tuesday, 27 June 2017 at 18:41:00 UTC, Random D user wrote:
>> 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 :).

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.

Please, please, please, just do the same as clang.

On Tuesday, 27 June 2017 at 19:39:25 UTC, deadalnix wrote:
> Please, please, please, just do the same as clang.

I don't think clang has this feature, so doing the same as clang would be a regression. We're in uncharted waters!

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

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.

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.)

Am 27.06.2017 um 16:32 schrieb Vladimir Panteleev:
> 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.

On Tuesday, 27 June 2017 at 20:19:14 UTC, Sönke Ludwig wrote:
> 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

Am 27.06.2017 um 22:35 schrieb Vladimir Panteleev:
> On Tuesday, 27 June 2017 at 20:19:14 UTC, Sönke Ludwig wrote:
>> 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.

On Tuesday, 27 June 2017 at 21:10:37 UTC, Sönke Ludwig wrote:
> 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.