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"? The above looks OK to me although I prefer "color" (and allowing "colour" for our non-U.S. English speakers). 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. 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. 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. 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. Also please don't worry about updating copyright years: I have a utility that does that automatically for all the files at once. -- ------------------------------------------------------------------------------- Paul D. Smith <psm...@gnu.org> Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net "Please remain calm...I may be mad, but I am a professional." --Mad Scientist _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
