Re: [rfc] Colorized output for GNU make?

[Sebastian Pipping]

Hello, great to hear from you.


On 01/04/2012 02:06 AM, Paul Smith wrote:
> On Sun, 2012-01-01 at 01:31 +0100, Sebastian Pipping wrote:
>>> I have to say that I feel that David's
>>> point of 20 Oct is well-taken, that a more flexible command line
>>> interface would be better.
>>
>> Alright.  I propose to transform
>>
>>   --output-format=(color|plain)
>>
>> into
>>
>>   --format=(plain|colorized) .
>>
>> What do you want the parameter to look like?
> 
> I'm not sure what you mean by "the parameter"?

Sorry.  I was referring to all of "--format=(plain|colorized)" not just
the "(plain|colorized)" part.


>  The above looks OK to me
> although I prefer "color" (and allowing "colour" for our non-U.S.
> English speakers).

Good.


> As for the code, I have a concern about the way strings are being
> constructed.  One of the hardest parts about generating output in a GNU
> program is the requirement to support i18n.  GNU make is not perfect but
> it is making strides and I think the new behavior actually moves us a
> step backwards.  I'm thinking in particular of the PREFIX capabilities.
> 
> The problem is that not all languages are read left-to-right: some are
> read right-to-left.  So, if you create output strings with prefixes that
> are generated first and not part of the translated string, then those
> prefixes cannot be "swapped" for languages that are read right-to-left:
> they always come on the left, when they should come on the right.
> 
> Some of the output we generate, such as the error() function, already
> has this problem.  But in other areas we avoid it by constructing the
> string completely including the prefix, and translating that.
> 
> I confess I'm not an expert in i18n, so it's quite possible I'm making
> something out of nothing very important here.  But I think it's worth
> investigating.  It's possible, for example, that it's sufficient to
> "translate" the prefix string itself if everything is printed in one
> invocation.

I see.  I'm all for a proper solution to that.

With output like "make[4]: foo failed" pushing full control into
translation strings seems troublesome to me.  Imagine

  "%s[%u]: foo failed"
  "%s[%u]: bar failed"
  ...

in the translation database.  It doesn't get much better with

  "make[%u]: foo failed"
  "make[%u]: bar failed"
  ...

What do you think about specify a reading direction for each supported
language and making use that information to select from prefix or suffix?

With that information pure translation strings

  "foo failed"
  "bar failed"

can be turned into either

  "make[4]: foo failed"
  "make[4]: bar failed"

or

  "foo failed: make[4]"
  "bar failed: make[4]"

or even

  "foo failed: [4]make"
  "bar failed: [4]make"

on the fly.

If translation allows strings only we could let people translate
"READING_DIRECTION" to "LEFT_TO_RIGHT" or "RIGHT_TO_LEFT" and assume
left-to-right unless we get a match for "RIGHT_TO_LEFT".


What do you think?


> Beyond that, I'm not excited about having to add a parameter specifying
> whether there's a newline or not.  I'm assuming that if you don't switch
> back the color to the default before the \n is printed, you get ugly
> output, is that it?  I'd actually prefer the output.c code to be a
> little more complex and check to see if the string ends in a newline and
> handle that internally, rather than have all the callers have to pass a
> special flag specifying newlines.

I can implement that and resolve the flag, no problem.


> Ditto for the flush() call.  I'm not sure why we'd ever want to NOT
> flush, and I'm not sure why there's an explicit flush() some places but
> not others.

Alright, let it always flush.

> 
> If we do end up needing extra flags, I wonder if there's some way to
> combine them with the message type to avoid needing an extra parameter.

As you wish.


> Also please don't worry about updating copyright years: I have a utility
> that does that automatically for all the files at once.

Noted.

Best,



Sebastian