Let's paint those bikesheds^Werror messages!

[Sönke Ludwig via Digitalmars-d]

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

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