Re: RFC: color diagnostics markers

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

On Wed, Apr 10, 2013 at 12:54 PM, Manuel López-Ibáñez
<lopezibanez@gmail.com> wrote:
> On 8 April 2013 21:06, Jakub Jelinek <jakub@redhat.com> wrote:
>> On Mon, Apr 08, 2013 at 07:54:18PM +0200, Manuel López-Ibáñez wrote:
>>> > can be right now a single call, while you would need several.  Also, if you
>>> > eventually want to colorize something in say error_at, warning_at and
>>> > similar format strings.  For those you really don't have the printer at
>>>
>>> Do we really want to allow that much flexibility? Then the color_dict
>>> needs to be dynamic or the caller is restricted to re-using existing
>>> colornames.
>>
>> Yes, I think we want that flexibility, it certainly isn't that much
>> difficult to support it (a few lines of code, will try to code the %r/%R
>> variant tomorrow), and from time to time it can be useful.
>
> I am still not convinced by the %r/%R. My two concerns are that:
>
> 1) %r/%R rather than explicit function calls make the code harder to
> understand. But I guess this is a matter of taste.
>
> 2) It makes harder to decouple the diagnostics machinery from the
> actual formatting. The color should be something handled by the
> pretty-printer and transparent to the diagnostics machinery interface.
> (perhaps it should be pretty-printer-color.h instead of
> diagnostics-color.h). I generally agree with the ideas of Gabriel
> exposed here: http://gcc.gnu.org/ml/gcc/2012-04/msg00558.html. The
> difference (and perhaps I misunderstood Gabriel's position in that
> thread) is that I think that hiding the color stuff behind the
> diagnostics machinery interface does not move us farther away from
> those ideas, even thought it does not move us closer either. And we
> don't need an internal IL to do that.  However, letting the FEs add
> arbitrary colors to diagnostics does move us farther. Yes, it is a
> nice flexibility, but on the other hand, I don't really see the need
> and I am afraid it will be misused. As Gabriel says: "it would be
> really terrible idea if the intelligibility of a diagnostic -requires-
> colors.". So if the color is not required, the FE should be oblivious
> to whether there is a specific color there or not.
>
> Nonetheless, I am pragmatic. Since you already did the work (and
> improved significantly my original patch), I am fine with your patch
> (for what is worth). Thanks for working on it.
>
> Cheers,
>
> Manuel.

We might be saying the same thing using different languages.

I was the %r/%R markers are ways of implementing the IL language
I suggested in that message.  So, as such I do not object to it.
Having an explicit call makes the FE makes a "colorful" formatting
decision way too early -- a FE shouldn't be concerned about color matters.
That decision should be left to the device doing the formatting.  Separation
of concerns here isn't just taste; it is good engineering practice.

-- Gaby