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:
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
Then, your eyes can just look for the color and realize which
candidate is the best match and immediately see what you're
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
Big, big win on my eyes.