On Wed, Apr 10, 2013 at 12:54 PM, Manuel López-Ibáñez <lopeziba...@gmail.com> wrote: > 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.
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
