<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><div class="h5"><div>My problem is this: thus far, Clang's colors, bold, and other markup of the textual output don't add any information, they just make the information displayed easier to read. I like that distinction, because we have a lot of users who will at some points not have color or bold available when looking at the text. This happens either due to disabilities, deficient terminals, terminal preferences, ssh silliness, or because the diagnostics have gone through a layer of textual logging that tried to strip escape codes. Lots of different reasons this can happen.</div>
</div></div></div></blockquote><div><br></div><div>Actually I was tossing around some ideas about using colors in this way (ie: in a way that wouldn't be simply highlighting existing text, but using colors instead of existing text, etc) as one way to address a bug in the existing formatting of multiple fixits ( <a href="http://llvm.org/bugs/show_bug.cgi?id=10696">http://llvm.org/bugs/show_bug.cgi?id=10696</a> ). With inline highlighting we could potentially do a much nicer job for colored console users. For those lacking color we could just drop them when they're going to overlap (as per Chris's suggestion) or find some more verbose description (I'm still thinking that inserting whitespace might be an interesting idea - to line up the fixits/removals with each other, but I suppose that'd require the diagnostic printer to be token aware which it probably isn't currently)</div>
<div><br></div><div>For the current issue at hand - I'm with Doug on this. I think visual highlighting could add a lot of value over any solution that tries to be terminal coloring agnostic. That's not to say that we can't provide some degraded experience to non-colored users, but I think it will be inherently worse than highlighting.</div>
<div><br></div><div>As for how to do it - the diagnostic builder would have to be aware of any pairs of inserted tokens that are meant to be equal, basically (this could be described in syntax similar to the current diagnostic select mechanism, perhaps? "Argument type %equal{0}1 doesn't match parameter value %equal{1}0" ?<br>
<br>Then the DiagnosticBuilder (admittedly I don't know the full diagnostic stack, so I don't know if this decision would have to be deferred until even later) could use color highlighting or, in the absence of that, could print two lines. Perhaps we could have a requirement that the diagnostic using %equal must have the following diagnostic ID being the other textual form such as "The following types do not match" (or build it more tightly into a single diagnostic switching between two textual forms). <br>
<br>Is that the sort of direction we're talking about here?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote">
<div>As a result, I've found it very important that the user can usually get the full benefit of the improved diagnostic even w/o these nice-to-have markups. This is the first time (I think) that we're adding a really significant amount of logic to convey information that would be lost without the colors / markup. (Another interesting example is that we break the underlining of source ranges into ~s on a separate line in ascii art rather than using the underlining escape codes.)</div>
</div></blockquote><div><br></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. <br>
</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>Can you think up a way to not have to make this compromise? That is, could we present this information in a way that didn't require colors or other special terminal features *and* didn't have the downside of notes (searching, etc)? I haven't been able to, but that would be my preference. While I would love to take advantage of a more rich medium when available (*cough* IDEs make this easy *cough*), I'd like to get as much of this benefit into the plain-old-text output as possible, with the understanding that we have a lot of users which will loose some or all of the markup we apply to the text...</div>
</div></blockquote><div><br></div><div>Certainly if we can come up with a way that's great, but I certainly wouldn't rule out having two different formatters - one for colors & escape codes (or even color, color + escapes, pure text, 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>The current output matches almost exactly what several users told us they did in order to read the existing diagnostics: they cut/pasted the type into an editor, and deleted the similar parts. My intuition is that users will actually like having these elements broken out, as well as having the complete types, but it seems like our intuition about how users are reading these diagnostics differs.</div>
</div></blockquote><div><br></div><div>I'm not sure there's a difference in intuition here - what you describe is probably the easiest way for a user to do this diff visually - it doesn't mean it's the best way for a program to do it to present that information to a user. </div>
</div>