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

[David Blaikie]

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

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.

Certainly we can toss around a few different syntax ideas & see how they
look compared to colored highlighting options, etc.


> 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.
>>
>
> Again, there is an important difference between "less value" and "less
> information".
>

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.

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

So to summarize, these were/are my ideas:

1) keep the message text/syntax the same, add information to diagnostic
strings to describe matched pairs, highlight differences in color.
   => color users get a better experience, uncolored users get the same
experience they have today (effectively they don't get this bug fix)
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)
   => 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)
3) I suppose is basically (2) but just provide the out-of-line diagnostic in
all cases, highlighted with color where available

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.

- David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20110829/c74a22b3/attachment.html>