[RFC] ColorD

[Chad J]

On 10/22/2012 03:47 AM, Jens Mueller wrote:
> Chad J wrote:
>> There is no weakness to this.  The only shred of a counterargument I
>> can think of is that it makes the format strings more difficult to
>> learn. Other than that, it is possible to detect the destination of
>> the formatter, so color codes will never end up in places where they
>> shouldn't.  A conservative approach to this should handle most
>> desires and never interfere with all the people with no interest in
>> color.
>>
>> On the upshot are the things I've mentioned:
>> - A format specifier is potentially more discoverable.
>> - A format specifier is more concise.  This keeps your lines from
>> wrapping.  They are probably too long already.
>
> Do you consider this
> writecf(Color.red, "something %s", "here")
> concise as well?
>

The case is too easy.  You're formatting an entire line.

>> - To cement the previous point: nesting requires a few extra
>> characters with a format specifier, rather than a couple extra
>> /lines/ for extra function calls.
>
> Don't understand this point. Can you give an example?
>

Option A:

     auto save = getConsoleState();
     scope (exit) setConsoleState(save);
     setConsoleColors(Fg.red, Bg.blue);
     writeln("Red text on blue background.");

Option B:

     writefln("%CFredBblu(Red text on blue background.%)");

>> - Calls to stateful console functions allow people to write bugs
>> like saving console state and then forgetting to restore it (or
>> throwing an exception and neglecting to restore from within a scope
>> guard).  Format specifiers do not have this problem.
>
> The same holds for
> writecf(Color.red, "something %s", "here")
>

See my above example.  In that case the formatter no longer requires 
even using the scope feature because there are no resources to clean up. 
  The library handles that mess.

Also statefulness is a pain to deal with.  Stack-like operation with 
push/pop or bracketing constructs is usually much less troublesome for 
this sort of thing.

>> - etc (I'm sure I'm forgetting one or two.)
>>
>> These are the reasons why my ideal language has color formatting
>> built into its I/O routines.
>
> Just wanted to point out that instead of that you can add writec*
> functions. I think the only thing is that these are less discoverable
> but they also work without formatting, e.g.
> writec(Color.red, "my text");
>

The thing I found very difficult with other color formatting APIs was 
formatting individual words or characters.  Entire lines are easy-peasy 
stuff in any API.  Solving the entire-lines case won't impress me. ;)

Here's my more typical use case:

writefln("The %CFred(widgetometer%) is a device for measuring");
writefln("widget effectiveness.  It is possible to ");
writefln("reconcile transcendental properties by hitting");
writefln("%CFblu(B%) for blue coefficients, %CFgrn(G%) for green");
writefln("coefficients, or %CFyel(Y%) for yellow coefficients.");
writefln("Here is a correspondence table:");
writefln("  %CFnue( %) | %CFblu( B %) %CFgrn( G %) %CFyel( Y %) ");
writefln("  %CFnue(-%)-+-%CFnue(---%)-%CFnue(---%)-%CFnue(---%)-");
writefln("  %CFblu(B%) | %CFblu(200%) %CFwht(330%) %CFwht(303%) ");
writefln("  %CFgrn(G%) | %CFwht(110%) %CFgrn(020%) %CFwht(033%) ");
writefln("  %CFyel(Y%) | %CFwht(101%) %CFwht(011%) %CFyel(002%) ");

I realized that I wanted a "nue" color that has no effect but allows me 
to align things effectively ;)

Anyhow, please try to write the above example using any other style. 
Interleaved function calls are particularly "fun" <g>