May 16, 2017
On Tuesday, 16 May 2017 at 14:04:34 UTC, Walter Bright wrote:
> With all the complaints about color, note that dmd already has been using color in error messages for years with no complaints

My complaint isn't about the presence of color* but rather about the OVERUSE of it.

The old way of coloring the message header helps you quickly find the beginning of an error among output spam. It stands out. But now, with color being all over the place, you can't visually scan for it anymore. It loses its special meaning.

Similarly, what I want to see in the future is highlighting of specific parts of code where the error applies.

Error: No overload for foo(int), candidates are:
  foo(string);
  foo(int, string);

In my perfect world, `Error` is colored, like it is now, you can scan for it and find that. Then, the first `string` is also highlighted as a mismatch of the overload, and the `int` in the candidate signature is also highlighted as a match of the overload.

Then, your eyes can just look for the color and realize which candidate is the best match and immediately see what you're missing.



With syntax highlighting though, string and int will be highlighted as types or keywords... which is irrelevant to the issue of matching the correct overload. It stands out, but means nothing. And if everything is colored, yikes, then nothing stands out since you can't even eye scan it at all.



So again it is NOT color that bothers me. It is OVERUSE of color for stuff that isn't important to read the message which dilutes the meaning of color. It isn't special anymore.



* I did hate it for a while though because the contrast was poor, but I fixed that with some hack to my terminal emulator code to give it a superior adaptive palette. Perhaps tilix's author will want to do this too: mine has a different yellow when printed on white than on black, different blue, different teal. The application outputs the same sequence but my thing is aware of the background and adapts. Even if the application tries to output unreadable stuff explicitly, my terminal emulator won't allow it.

Big, big win on my eyes.
May 16, 2017
On Sunday, 14 May 2017 at 14:07:20 UTC, Walter Bright wrote:
> https://github.com/dlang/dmd/pull/6777
>
> It turned out to be unexpectedly easy to implement.
>
> The only downside is now we have to rather tediously tweak the error message texts so they use backticks.

The next step is Color D...

https://github.com/narke/colorForth

-=mike=-
May 16, 2017
On 5/16/2017 7:17 AM, Adam D. Ruppe wrote:
> So again it is NOT color that bothers me. It is OVERUSE of color for stuff that
> isn't important to read the message which dilutes the meaning of color. It isn't
> special anymore.

Perhaps. I know I have some trouble distinguishing code from explanatory text in error messages, particularly when the code looks like english, as in:

    error: undefined identifier maybe

Colorizing code distinguishes it from text.

The initial color choices I picked are garish on purpose, it's to try things out. I expect to change it to more muted ones (turn off the intensity bit at least). It's also possible to use underlining.

I'm working on the next PR that will auto-detect if Adam is running the compiler, and will highlight code with blinking text.


May 16, 2017
On Tue, May 16, 2017 at 08:11:21AM -0700, Walter Bright via Digitalmars-d-announce wrote:
> On 5/16/2017 7:17 AM, Adam D. Ruppe wrote:
> > So again it is NOT color that bothers me. It is OVERUSE of color for stuff that isn't important to read the message which dilutes the meaning of color. It isn't special anymore.
> 
> Perhaps. I know I have some trouble distinguishing code from explanatory text in error messages, particularly when the code looks like english, as in:
> 
>     error: undefined identifier maybe
> 
> Colorizing code distinguishes it from text.
[...]

Simpler solution: print the identifier in quotes, e.g.:

     error: undefined identifier 'maybe'

There: instantly clear without needing any colors.


T

-- 
LINUX = Lousy Interface for Nefarious Unix Xenophobes.
May 16, 2017
On Tuesday, 16 May 2017 at 15:11:21 UTC, Walter Bright wrote:
>     error: undefined identifier maybe
>
> Colorizing code distinguishes it from text.

What's important there? The generic syntax that you get from a syntax highlighter or the fact that it is the user input?

Drawing attention to `maybe` there is a good idea! But that's not because it is syntax highlighted, it is because that's the most important word in the message.

(btw I think it already has attention because of its placement, it doesn't need additional color. but the case I keep going back to, function overloading, puts important stuff in the middle of the message and that would be nice to stand out, as long as what's important - the mismatched arguments - are what stand out)

> It's also possible to use underlining.

Yeah, on some systems, but not really on Windows or even all linux terminals. Color has broader support, though you do want to be careful not to *depend* on color either.

> I'm working on the next PR that will auto-detect if Adam is running the compiler, and will highlight code with blinking text.

I'm afraid that won't work, my terminal emulator doesn't support blinking.

But if it detected it was me and outputted XML error messages, oh boy, I'd be excited about that! I honestly very much would love xml error messages.
May 16, 2017
On 5/16/2017 8:13 AM, H. S. Teoh via Digitalmars-d-announce wrote:
> Simpler solution: print the identifier in quotes, e.g.:
>
>      error: undefined identifier 'maybe'
>
> There: instantly clear without needing any colors.

I know about the quotes. With longer message lines, they get lost.

To turn off color, just add:

   -color=off

to your dmd.conf file.

May 16, 2017
On Tuesday, May 16, 2017 08:11:21 Walter Bright via Digitalmars-d-announce wrote:
> On 5/16/2017 7:17 AM, Adam D. Ruppe wrote:
> > So again it is NOT color that bothers me. It is OVERUSE of color for stuff that isn't important to read the message which dilutes the meaning of color. It isn't special anymore.
>
> Perhaps. I know I have some trouble distinguishing code from explanatory text in error messages, particularly when the code looks like english, as in:
>
>      error: undefined identifier maybe
>
> Colorizing code distinguishes it from text.
>
> The initial color choices I picked are garish on purpose, it's to try things out. I expect to change it to more muted ones (turn off the intensity bit at least). It's also possible to use underlining.
>
> I'm working on the next PR that will auto-detect if Adam is running the compiler, and will highlight code with blinking text.

LOL. Or you could have it just say:

"I'm sorry, Adam. I'm afraid I can't do that."

:)

https://www.youtube.com/watch?v=OEu4Iq5KL-Q

- Jonathan M Davis

May 16, 2017
On 5/16/2017 8:25 AM, Adam D. Ruppe wrote:
>> It's also possible to use underlining.
>
> Yeah, on some systems, but not really on Windows or even all linux terminals.
> Color has broader support, though you do want to be careful not to *depend* on
> color either.

I've never met an ASCII console that didn't support underlining. This includes the ones I used back in the 1970's, and includes the tty I designed and built myself for a class project. It includes DOS and Windows consoles.

Underlining enjoys much broader support than color does. Color became fairly ubiquitous rather late, in 1990 or so. The VT-100 control sequences have effectively replaced all the other ones.

> my terminal emulator doesn't support blinking

Then yours is a unique snowflake, as it's standard for VT-100 emulation (xterm).

May 16, 2017
On Tuesday, 16 May 2017 at 15:38:53 UTC, Walter Bright wrote:
> It includes DOS and Windows consoles.

Only under specific circumstances. On the VGA hardware, underline shares a bit with blue and needs a register tweaked to make it visible (the default 16 color VGA text mode does NOT display the underline), and only worked on CJK multibyte output on Windows 2000 through Windows 10.

Only recently, with the one of the updates to windows 10, was console underlining added to Windows for English text, as part of their Linux terminal compatibility flag (see: ENABLE_VIRTUAL_TERMINAL_PROCESSING).

> Then yours is a unique snowflake, as it's standard for VT-100 emulation (xterm).

It isn't really unique, rxvt treats it as bold and xterm can have it compiled out. I do recognize the sequence and even set the bit (see: https://github.com/adamdruppe/terminal-emulator/blob/master/terminalemulator.d#L1724 ) but then ignore it on the drawing side since blinking is a pointless distraction.

In practice, basic color support is pretty broad and reliable, given you remember that there's a human reading it who can't see poor contrast easily and a large percentage of them cannot reliably tell all colors apart. Underline, however, is not broadly supported by the computer console apis.
May 16, 2017
On Sunday, 14 May 2017 at 14:07:20 UTC, Walter Bright wrote:
> https://github.com/dlang/dmd/pull/6777
>
> It turned out to be unexpectedly easy to implement.

Nice.

But color highlighting should always be configurable (otherwise it's half done), because there are a lot of people who like colors, but can't distinguish between certain color combinations, because of a color disability. Or they might have poor displays or viewing conditions etc.

I guess this should be simple to add, just output the colors into an .ini file and read them back if the file exists.