[RFC] ColorD

[Chad J]

On 10/23/2012 03:51 AM, Jens Mueller wrote:
> Chad J wrote:
>> 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.
>
> Am I? I think it's not a line. But I see your point.
> You mean something like
> writec(Color.red, "red")
> writec(Color.blue, "blue")
> writec(Color.green, "green")
> is too verbose.
> You want something like
> writef("%CFred(red%)%CFblue(blue%)%CFgreeng(reen%)");
> Right?
>
>>>> - 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.%)");
>
> I see. Though I find the last line difficult to decipher (because there
> are no spaces).
>
>>>> - 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.
>
> It'll be nice then if you can built something using format specifiers on
> top of a basic library.
>
>>>> - 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. ;)
>
> I see your point now. But we should keep it simple.
>
>> 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>
>
> I'm convinced. But I find that it difficult to read. Though that's a
> problem I usually have with format strings. Can these format strings be
> made easier to read. I mean
>
> writefln("The %CF(red)(widgetometer) is a device for measuring");
> or
> writefln("The %c(red,white)(widgetometer) is a device for measuring"); // for writing red on white
>
> is already easier to my eyes.
> I'd be happy to see it built on top.
>
> Jens

That's a reasonable suggestion.  The only thing that can't be solved is 
the trailing ) enclosing the text to be formatted.  That needs a % 
before it to prevent ambiguity with parentheses in the text itself.  So 
I could make your example:

 > writefln("The %c(red,white)(widgetometer%) is a device 
formeasuring"); // for writing red on white

I was also considering the possibility of separating layout and style by 
allowing some kind of style specification before the printing, with a 
limited formatting spec for using the styles:

stdout.addTermTextStyle("id=myStyle, fg=red, bg=white, dark, underline");

writefln("The %c(myStyle)(widgetometer%) is a device for measuring");