On Wed, Apr 4, 2012 at 1:58 PM, Ken Barber <[email protected]> wrote:
> > Invoking Windows' native color support changes the color of the pen at
> that
> > particular moment, tightly coupling the colorization time with output
> time.
> > In Facter, this is less of a big deal, since you're effectively
> choosing to
> > style content based on its type at output time. In Puppet, especially
> with
> > the work done on the module tool (and moving forward into Telly), we're
> > seeing a distinct need to decouple those processes. For example, if I
> want
> > to colorize only version numbers in the module tool's output, a tight
> > coupling means that I have to (in the worst case):
> >
> > * Decompose the output message on version number boundaries
> > * Iterate over those "chunks" of the output
> > * Print each "chunk" with an appropriate color
> >
> > If I decide to start coloring any other part of the output as well (say,
> > module names), the problem gets more expensive.
> >
> > Injecting ANSI escape sequences into the string as a form of markup
> > (inelegant as it is) gives us flexibility -- we could, in that same
> example,
> > run a quick s///g and have colorized the string appropriately. While we
> > could easily write our own handler to intercept those escapes on Windows
> and
> > change the pen color at output time, that's exactly what libraries like
> > ansicon and win32console are doing for us.
>
> Okay - I understand the need to store away variables and re-use them
> later and the issues related to when you colorise them so I can see
> your point.
>
> I guess using the color_print methodology does require a prior
> decomposition that literally applies labels to sections of text. But
> this was intentional I assure you.
>
> Of course you could do this in other ways as well, I originally
> experimented with using labels in the string such as:
>
> print "#{t.color(:green)}My green text{#t.color(:reset)}"
>
> My goal here was to avoid having to have people enter the ANSI/SGR
> codes themselves. But this wasn't going to work with the win32api - as
> the method (t.color) was evaluated before the string was processed
> :-). This could still work with win32console using ANSI escape
> characters.
>
> I guess on a similar note to solve the scheme problem one could do
> something like:
>
> print "#{t.color(:strings)}\"foobar\"#{t.color(:reset)}"
>
> Or some such. Then we can still replace these with the correct escape
> codes in a central place - thus still achieving my scheme solution.
>
> ken.
I think we're on the same page. The way
Puppet::Util::Colors<https://github.com/puppetlabs/puppet/blob/master/lib/puppet/util/colors.rb#L77>is
implemented is in pursuit of the same goal. While we don't (yet) have
semantic class names, we definitely *don't* want anyone to have to write
their own escape codes.
include Puppet::Util::Colors
red_string = colorize :red, "this string is (#{ colorize :blue,
'mostly' }) red"
puts colorize(:green, "--> #{red_string} <--")
(When we have fleshed out our color vocabulary, it should be very simple to
add semantic names to this module.)
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
