<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div class="im"><div>The problem is *how* you provide the degraded experience. Sure, in some cases, the clang driver detects whether or not we have a terminal available that can render colors. However, there are many cases where *after* that detection occurs, the colors are then stripped out by various pieces of software. This can happen with screen, ssh, log processing, some defective terminals, etc. That means that we don't have the opportunity to generate more text at the moment the color gets stripped. The worst case scenario for me are problems of colorblindness. ;]</div>
</div></div></blockquote><div><br></div><div>True enough - though we do have -fno-color-diagnostics for such situations. But it's a fair point - users would have to go out of their way to disable them (& it wouldn't be obvious "this diagnostic makes no sense" because it relied on coloring). Classic UI design supports your position - you're not meant to rely on colors to communicate information (for color blind users, different color meaning in different cultures, etc) but it's not always ideal for users who can use color, especially in a terminal where there's such limited information density.</div>
<div><br></div><div>Certainly we can toss around a few different syntax ideas & see how they look compared to colored highlighting options, etc. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div><div>I don't think it's hard to believe that highlighting (& other things we can do with a terminal) adds value & thus non-colored users (for any/all of the reasons you cite) are going to get less value. </div>

</div></div></blockquote><div><br></div></div><div>Again, there is an important difference between "less value" and "less information".</div></div>
</blockquote></div><br><div>Hence the proposal for different formats for different scenarios (color/non-color), though that does have the problem with users getting color output that they aren't/cannot use in one way or another.<br>
<br>But even in the worst case, this wouldn't degrade the non-color user's experience, it just wouldn't improve it. (which isn't to be dismissed, just to keep things clear/in perspective).</div><div><br></div>
<div>So to summarize, these were/are my ideas:<br><br>1) keep the message text/syntax the same, add information to diagnostic strings to describe matched pairs, highlight differences in color. </div><div>   => color users get a better experience, uncolored users get the same experience they have today (effectively they don't get this bug fix)<br>
2) provide two different message texts, one inline ("The parameter type 'blah' isn't the same as the argument type 'blah'") and one out of line ("The parameter and argument types do not match",%0,%1)</div>
<div>   => color users who can't see color (colorblind, program munging, etc) get the old experience, which is still functional if not as usable as these improvements. (effectively they don't get this bug fix)<br>
3) I suppose is basically (2) but just provide the out-of-line diagnostic in all cases, highlighted with color where available</div><div><br></div><div>Then the question is whether the language/presentation of the out of line message is so much worse that it's worth enhancing the experience for color users by providing it inline. Guess we'd have to look at the grammar of a few of these kinds of diagnostics to decide what the loss/gain is there.<br>
</div><div><br></div><div>- David</div>