> From: Paul Smith <psm...@gnu.org>
> CC: Eli Zaretskii <e...@gnu.org>, bug-make@gnu.org
> Date: Thu, 5 Jan 2012 17:32:50 -0500
>
> 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.
Indeed.
> 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?
To me, it does. A lot.
Thanks.
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
