> I see where you're going, but I'm still concerned.
What I've attempted to solve here is not just setting a fixed color to
a part of a string, but defining the string to be defined as part of a
scheme that can later be changed. Then, I apply a color to the scheme.
That way scheme changes are centralised. To be honest, I did this as
an after-thought after implementing color_print as it seemed easy
enough to do. I guess thats why I've sent this around - to see what
people think.
> 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.
--
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.
