[RFC] ColorD

[Jens Mueller]

Chad J wrote:
> On 10/23/2012 04:42 PM, Jens Mueller wrote:
> >Jens Mueller wrote:
> >>Chad J wrote:
> >>>
> >>>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");
> >>
> >>Ideally, we get some users and ask them what they find easy to read. Or
> >>look how other languages solve this.
> >>Because I myself don't color my terminals that much I find it hard to
> >>imagine.
> >>I searched for some ruby libraries. I find ruby syntax often very easy.
> >>We could use UFCS, e.g.
> >>"some string".red
> >>or
> >>"some string".foreground(Color.red)
> >>
> >>What do you think?
> >>I find this way easier than format strings.
> >
> >Just read the other post. This has the same problem.
> >
> >Jens
> 
> Also I'm intentionally shooting for something very concise.  If
> verbosity conflicts, then it loses.  I say verbosity because I find
> that things get /less/ readable in situations like these if the
> syntax/naming is lengthy.  It causes alignment issues, text
> wrapping, noise, etc.
> 
> The thing I liked about the styling notion is that it allows things
> to be spelled out more, but places this noise outside of the string
> being formatted.
> 
> More thoughts:
> 
> // Do style parsing at compile-time if desired.
> const myStyle = parseTermTextStyle("id=myStyle, fg=red, bg=white,
> dark, underline"
> 
> // At runtime, stdout is told to use this.
> stdout.addTermTextStyle(myStyle);
> 
> // I'm thinking it might look better by dropping a pair of parens,
> //   but using a . to make it clear where the formatter type ends
> //   and the style id begins.
> writefln("The %C.myStyle(widgetometer%) is a device for measuring");
> 
> // Overloaded for convenience.
> stdout.addTermTextStyle("id=rw, fg=red, bg=white, dark, underline");
> 
> // The user can choose how verbose they want their formatter to look.
> // This is a very concise one.
> writefln("The %C.rw(widgetometer%) is a device for measuring");
> 
> // Other note: %C is necessary.  %c can't be used because that is
> //   already used for formatting single characters.

I think is too complicated.
It needs to be a one liner.
Here is an idea:

struct Proxy
{
    this(string s)
    {
        _s = s;
    }

    this(this)
    {
        _s = _s.idup;
    }

    string toString()
    {
        _oldColor = stdout.foregroundColor(Color.red);
        return _s;
    }

    ~this()
    {
        stdout.foregroundColor(_oldColor);
    }

    Color _oldColor;
    string _s;
}

@property
Proxy red(string s)
{
    return Proxy(s);
}

unittest
{
    writeln("string".red);
}

It works in this case. Not sure about the implications of such an
implementation.

Jens