Re: RFC: color diagnostics markers

[Jakub Jelinek <jakub at redhat dot com>]

On Wed, Apr 10, 2013 at 09:04:06PM -0500, Gabriel Dos Reis wrote:
> 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.

But the decision is left to the device doing the formatting.
The %r/%R only says, this text in between is of this kind (locus, quote
(well, that is automatically done by the patch also for %</%> and %qs etc.),
etc.), and we either color that using GCC_COLORS (or default) defined color
if requested through command line option and terminal supports it, or we
don't.

As discussed earlier, alternative to the current uses of %r/%R in the
sources would be %U (first and only letter from locus that is still available)
which would take location_t and would perform on it:
  expanded_location el = expand_location (va_arg (ap, location_t));
  pp_string (pp, colorize_start (pp_show_color (pp), "locus"));
  pp_string (pp, el.file);
  pp_colon (pp);
  pp_decimal_int (pp, el.line);
  if (context->show_column && el.column)
    {
      pp_colon (pp);
      pp_decimal_int (pp, el.column);
    }
  pp_string (pp, colorize_stop (pp_show_color (pp)));
or so.  But I wonder if we won't need %r/%R in the future, or add more and
more formatting codes, say if we wanted to highlight something that isn't
to be quoted around, or some substring inside quotes.  With %r/%R we have
the flexibility to do so easily, with just %U we don't.

	Jakub