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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017