On Thu, 2012-01-05 at 22:42 +0100, Sebastian Pipping wrote: > On 01/05/2012 09:46 PM, Eli Zaretskii wrote: > > The easiest way of abstracting this is to have a function that turns > > on a given color, and another function that turns off a color and > > returns to the default color. ("Color" can actually be some other > > attribute, like bold or blinking.) There should be a way to do this > > separately for foreground and background colors. > > Is this about the extraction of two functions of three lines each or is > it about more?
It seems like we have two distinct things going on. The first one is creating a common infrastructure for formatting messages, so we can generate a single string to be printed: that's the prefix stuff etc. The second one is the colorized output itself: both the command line settings, as well as ultimately turning on/off colors. Today those two things are kind of stuck together, in a single file. If we wanted to, for example, support ncurses for output instead of direct ASCII control chars, it's not easy without duplicating a lot of common code for the formatting part. Or consider the other requests we saw on this list, where instead of the output being colorized it's printed in some kind of structured format for easier parsing (depending on the structure it would be hard to do this 100% because today we don't control the output of recipes... but if we integrated the "parallel program output synchronization" feature we could even potentially do this as well). Maybe a way forward would be to take the code that formats the messages into a string and move that code into misc.c or similar. That's generic and not related to colorizing. Then have a function that took a message string (constructed by the formatting function probably?), and some details about the kind of attributes to use, and put that function in a file like "output_ascii.c" or something with a well-defined interface, so other files like "output_ncurses.c" or whatever could be written to that same interface and dropped in. There might have to be some kind of handshake between the generic code and the colorized code for verifying command line arguments that set attributes, so the colorizing code can reject things it doesn't understand for example. Does that make sense? _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make