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

Reply via email to