This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFC: color diagnostics markers
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Manuel López-Ibáñez <lopezibanez at gmail dot com>
- Cc: Gabriel Dos Reis <gdr at integrable-solutions dot net>, "Joseph S. Myers" <joseph at codesourcery dot com>, Gcc Patch List <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 8 Apr 2013 21:06:20 +0200
- Subject: Re: RFC: color diagnostics markers
- References: <CAESRpQCG6VX4JTEXLhrV2LDCLENYB7i8ad-3jj=K6FGeuK5+Ug at mail dot gmail dot com> <20130402091449 dot GE20616 at tucnak dot redhat dot com> <CAESRpQAiDrn-9T7Zxvs2ZQVT9hE9_X=gnEyDkS7Y4b-vOiz3Cg at mail dot gmail dot com> <20130408132301 dot GO20334 at tucnak dot redhat dot com> <CAESRpQAz45k2SYVcEDn_oVkUuLVtGqChHRdgS0NQW5dVgrveLw at mail dot gmail dot com> <20130408144359 dot GP20334 at tucnak dot redhat dot com> <CAESRpQBXecse09cZ55_EhDzQno4K5Tid+N5beMG0JdOBLmLGJQ at mail dot gmail dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
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.
Perhaps that %L or whatever character isn't taken for the expanded location
could be used too.
> I was expecting the use of color to be rather limited to a very very
> few well-defined concepts. I was hoping that higher-level diagnostic
> functions would be oblivious to the color stuff to not make the
> diagnostics code much more complex.
I don't see why we would need dynamic color names, as the color names are
to be overridable through GCC_COLORS, documented in invoke.text etc., the
list better be static and not too long, but we can add new color names in
the future when needed.
Jakub