Re: Let's paint those bikesheds^Werror messages!
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
Re: Let's paint those bikesheds^Werror messages!
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.
Re: Let's paint those bikesheds^Werror messages!
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?
Re: Let's paint those bikesheds^Werror messages!
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 +, 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. >
Re: Let's paint those bikesheds^Werror messages!
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
Re: Let's paint those bikesheds^Werror messages!
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?
Re: Let's paint those bikesheds^Werror messages!
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-the-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
Re: Let's paint those bikesheds^Werror messages!
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/gfreuclhvrzpfgqro...@forum.dlang.org
Re: Let's paint those bikesheds^Werror messages!
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.
Re: Let's paint those bikesheds^Werror messages!
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
Re: Let's paint those bikesheds^Werror messages!
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
Re: Let's paint those bikesheds^Werror messages!
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
Re: Let's paint those bikesheds^Werror messages!
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.
Re: Let's paint those bikesheds^Werror messages!
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
Re: Let's paint those bikesheds^Werror messages!
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
Re: Let's paint those bikesheds^Werror messages!
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?
Re: Let's paint those bikesheds^Werror messages!
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.
Re: Let's paint those bikesheds^Werror messages!
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/dtlzlemqzfyozleks...@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).
Re: Let's paint those bikesheds^Werror messages!
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/dtlzlemqzfyozleks...@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.
Re: Let's paint those bikesheds^Werror messages!
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/dtlzlemqzfyozleks...@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.
Re: Let's paint those bikesheds^Werror messages!
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/dtlzlemqzfyozleks...@forum.dlang.org
Re: Let's paint those bikesheds^Werror messages!
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
Re: Let's paint those bikesheds^Werror messages!
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.
Re: Let's paint those bikesheds^Werror messages!
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.
Re: Let's paint those bikesheds^Werror messages!
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
Re: Let's paint those bikesheds^Werror messages!
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.
Re: Let's paint those bikesheds^Werror messages!
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.)
Re: Let's paint those bikesheds^Werror messages!
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.
Re: Let's paint those bikesheds^Werror messages!
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!
Re: Let's paint those bikesheds^Werror messages!
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.
Re: Let's paint those bikesheds^Werror messages!
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 :).
Re: Let's paint those bikesheds^Werror messages!
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.
Re: Let's paint those bikesheds^Werror messages!
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.
Re: Let's paint those bikesheds^Werror messages!
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.
Re: Let's paint those bikesheds^Werror messages!
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.
Re: Let's paint those bikesheds^Werror messages!
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.
Re: Let's paint those bikesheds^Werror messages!
On Tue, Jun 27, 2017 at 05:24:46PM +, 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.
Re: Let's paint those bikesheds^Werror messages!
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.
Re: Let's paint those bikesheds^Werror messages!
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!
Re: Let's paint those bikesheds^Werror messages!
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.
Re: Let's paint those bikesheds^Werror messages!
On Tue, Jun 27, 2017 at 02:32:28PM +, 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.
Let's paint those bikesheds^Werror messages!
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.
