www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Let's paint those bikesheds^Werror messages!

reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
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.
Jun 27
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
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.
Jun 27
next sibling parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
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.
Jun 27
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
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.
Jun 27
parent Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
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.
Jun 27
prev sibling next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
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.)
Jun 27
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2017-06-27 19:11, H. S. Teoh via Digitalmars-d 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.
Since an application cannot set any explicit colors, only symbolic names for colors, and they're limited to 16. It's up to the theme of the terminal emulator to make sure all colors look good on the chosen background color. -- /Jacob Carlborg
Jun 28
prev sibling next sibling parent reply FoxyBrown <Foxy Brown.IPT> writes:
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!
Jun 27
parent Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
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.
Jun 27
prev sibling next sibling parent reply qznc <qznc web.de> writes:
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.
Jun 27
next sibling parent Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
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.
Jun 27
prev sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
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.
Jun 27
prev sibling next sibling parent reply Random D user <no email.com> writes:
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.
Jun 27
parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
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.
Jun 27
parent Random D user <no email.com> writes:
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 :).
Jun 27
prev sibling next sibling parent reply deadalnix <deadalnix gmail.com> writes:
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.
Jun 27
parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
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!
Jun 27
parent deadalnix <deadalnix gmail.com> writes:
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.
Jun 27
prev sibling next sibling parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig+d outerproduct.org> writes:
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.
Jun 27
parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
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
Jun 27
parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig+d outerproduct.org> writes:
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.
Jun 27
next sibling parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
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.
Jun 27
parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig+d outerproduct.org> writes:
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
Jun 27
parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
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
Jun 27
parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig+d outerproduct.org> writes:
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.
Jun 27
parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
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.
Jun 27
parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig+d outerproduct.org> writes:
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).
Jun 27
next sibling parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
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?
Jun 27
next sibling parent reply Moritz Maxeiner <moritz ucworks.org> writes:
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
Jun 27
parent Mike Wey <mike-wey example.com> writes:
On 28-06-17 01:34, Moritz Maxeiner wrote:
 
 All these can even do true colors on Windows:
 - 
 https://blogs.msdn.microsoft.com/commandline/2016/09/22/24-bit-color-in-
he-windows-console/ 
 
On Windows 10, and in that case you can even use the vt100 escape sequences: https://msdn.microsoft.com/en-us/library/windows/desktop/mt638032(v=vs.85).aspx -- Mike Wey
Jun 28
prev sibling parent reply =?UTF-8?Q?S=c3=b6nke_Ludwig?= <sludwig+d outerproduct.org> writes:
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.
Jun 27
parent Moritz Maxeiner <moritz ucworks.org> writes:
On Tuesday, 27 June 2017 at 23:38:23 UTC, Sönke Ludwig wrote:
 Am 28.06.2017 um 01:24 schrieb Vladimir Panteleev:
 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.
Windows can do true colors [1] [1] http://forum.dlang.org/post/gfreuclhvrzpfgqroiib forum.dlang.org
Jun 28
prev sibling parent Moritz Maxeiner <moritz ucworks.org> writes:
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
Jun 27
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2017-06-27 23:10, Sönke Ludwig wrote:

 Just ruling out a white background would be
 a bad idea. I think on macOS that's the default, for example.
Yes, default background color on the default terminal emulator. -- /Jacob Carlborg
Jun 28
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/27/2017 7:32 AM, 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
In the spirit of this, a lot of (rather tedious) work needs to be done on the error messages themselves to enable color syntax highlighting. Specifically, replacing ' ' with ` `, and adding ` ` around %s formats when code is being emitted to the %s. It's tedious because of all the messages in test/fail_compilation/* that need updating. It would also be helpful to pull things like: https://github.com/dlang/dmd/pull/6890
Jun 27
prev sibling next sibling parent Gary Willoughby <dev nomad.so> writes:
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.
 - 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.
All of these points give added weight to this feature being opt in, not opt out. Why would we want to make output worse? Also, we shouldn't syntax highlight the message, just colour the whole line.
Jun 28
prev sibling next sibling parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 06/27/2017 10:32 AM, 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:
 
Hasn't DMD already been coloring error messages for about the past year? Or is it DUB that's been doing that to DMD's output? Or are we talking about something different then what was already there?
Jun 28
parent Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Thursday, 29 June 2017 at 01:45:11 UTC, Nick Sabalausky 
(Abscissa) wrote:
 Hasn't DMD already been coloring error messages for about the 
 past year? Or is it DUB that's been doing that to DMD's output? 
 Or are we talking about something different then what was 
 already there?
Please, click, the, link. Screenshots and details inside. https://github.com/dlang/dmd/pull/6943
Jun 29
prev sibling next sibling parent Danni Coy via Digitalmars-d <digitalmars-d puremagic.com> writes:
This times 1000

On Wed, Jun 28, 2017 at 3:11 AM, H. S. Teoh via Digitalmars-d <
digitalmars-d puremagic.com> wrote:

 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.
Jun 29
prev sibling parent reply bauss <jj_1337 live.dk> writes:
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.
Which is?
Jun 29
parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Thursday, 29 June 2017 at 14:33:19 UTC, bauss wrote:
 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.
Which is?
-color=off As with almost any other program, you can get a list of switches by running dmd --help. -color=[on|off] is the 7th switch listed.
Jun 29
parent bauss <jj_1337 live.dk> writes:
On Thursday, 29 June 2017 at 14:35:00 UTC, Vladimir Panteleev 
wrote:
 On Thursday, 29 June 2017 at 14:33:19 UTC, bauss wrote:
 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.
Which is?
-color=off As with almost any other program, you can get a list of switches by running dmd --help. -color=[on|off] is the 7th switch listed.
Thanks mate
Jun 29