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

On Tuesday, 27 June 2017 at 22:12:42 UTC, Sönke Ludwig wrote:
> [...]

(snip - as it boils down to needing a concrete proposal)

> 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

Um, I don't think that's possible. http://forum.dlang.org/post/dtlzlemqzfyozlekskdr@forum.dlang.org

Am 28.06.2017 um 00:19 schrieb Vladimir Panteleev:
> On Tuesday, 27 June 2017 at 22:12:42 UTC, Sönke Ludwig wrote:
>> [...]
>
> (snip - as it boils down to needing a concrete proposal)

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
>
> Um, I don't think that's possible.
> http://forum.dlang.org/post/dtlzlemqzfyozlekskdr@forum.dlang.org

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.

On Tuesday, 27 June 2017 at 22:34:39 UTC, Sönke Ludwig wrote:
> 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.

>> Um, I don't think that's possible.
>> http://forum.dlang.org/post/dtlzlemqzfyozlekskdr@forum.dlang.org
>
> 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.

Am 28.06.2017 um 00:44 schrieb Vladimir Panteleev:
> On Tuesday, 27 June 2017 at 22:34:39 UTC, Sönke Ludwig wrote:
>> 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.

>
>>> Um, I don't think that's possible.
>>> http://forum.dlang.org/post/dtlzlemqzfyozlekskdr@forum.dlang.org
>>
>> 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).

On Tuesday, 27 June 2017 at 19:43:03 UTC, Vladimir Panteleev wrote:
> 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!

Ho, sorry, this is syntax highlighting for the core itself, not the error messages. Well not sure, I'm no designer so I trust you guys to come up with something good.

On Tuesday, 27 June 2017 at 23:18:18 UTC, Sönke Ludwig wrote:
> 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?

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

On Tuesday, 27 June 2017 at 23:24:42 UTC, Vladimir Panteleev wrote:
> On Tuesday, 27 June 2017 at 23:18:18 UTC, Sönke Ludwig wrote:
>> 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?

All these can even do true colors on Windows:
- https://blogs.msdn.microsoft.com/commandline/2016/09/22/24-bit-color-in-the-windows-console/
- https://mintty.github.io/
- https://github.com/Maximus5/ConEmu

Am 28.06.2017 um 01:24 schrieb Vladimir Panteleev:
> On Tuesday, 27 June 2017 at 23:18:18 UTC, Sönke Ludwig wrote:
>> 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.