On 8 April 2013 21:06, Jakub Jelinek <ja...@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.
