How about colors and terminal graphics in std.format?

[James Miller]

On 13 March 2012 16:58, Chad J <chadjoan at __spam.is.bad__gmail.com> wrote:
> On 03/12/2012 10:37 PM, James Miller wrote:
>>
>>
>> I think the problem with putting it into formatting is that it is
>> inherently not output. IOW formatting should go anywhere, but colored
>> output is terminal-only.
>>
>> Also, there are differences between terminals and all sorts of crap
>> that just make this harder to do "simply". However, there's no reason
>> why there cant be an easy way to colorize output in std.terminal (or
>> whatever), that are basically just modified writef(ln) calls
>> (colorWritef?) that only output to stdout (and maybe stderr). I think
>> this would be a good way around it, because then everything that is
>> terminal-specific is kept in one place, and you don't get mistakes
>> like outputting color to a file because you did the wrong sequence, or
>> forgot to check that stdout is a terminal and all that.
>>
>> --
>> James Miller
>
>
> I do want to be able to format things besides color with the color
> formatting function.  Maybe I can pick out the color format specifiers first
> and then pass the rest to format.  It'd be a shame to reimplement format.
>
> At that point it would be cool if thrown exceptions and the like could do
> color formatting, and also know when to strip it out when writing to log
> files and such.  I don't know how difficult or practical it would be, but I
> think that stack traces with color highlights would be awesome.  It's pretty
> in-your-face user experience-wise too; might be good PR for D.
>
> So then, now for the fun part.  What to name this function?
>
> zoosmellPooplord(ln)("%Cred(Text.%)");

I wasn't suggesting to actually re-implement format, actually my idea
was similar to yours in that it would wrap over writef(ln). But doing
it this way, rather than extending writef, means that you can check
for output conditions first. It also allows people to realise that the
function they are reading /isn't/ just a bog-standard writefln, and
should be parsed (mentally) differently.

However, I think that any more than just sequential output should
probably have its own set of functions, so a clearLine function,
clearScreen function, setColor functions and all that. This also
suggests that a color-writef should reset to a "default" color at the
end of output, which makes sense.

One thing I would change is to not use syntax quite so similar to
writef though, and also (since it matches better with terminal
operation anyway) not have it wrap, just set the color for the
remaining output, otherwise parsing will be more difficult, since you
have to check for yet more escape sequences, and using it would be
more error-prone. (For an example, vim has some weird escaping rules
for its regex-implementation that catch me out all the time)

--
James Miller