[cfe-commits] Request feedback for new diagnostic feature - template type diffing

[David Blaikie]

>
> 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.
>

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 (
http://llvm.org/bugs/show_bug.cgi?id=10696 ). 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)

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.

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"
?

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).

Is that the sort of direction we're talking about here?

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.)
>

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.


> 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...
>

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).


> 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.
>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20110829/61cc717b/attachment.html>