How about colors and terminal graphics in std.format?

[Chad J]

On 03/13/2012 12:15 AM, James Miller wrote:
> 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.
>

Why?  This would be an addition of features for writef(ln), not an 
alteration.  Existing writef(ln) usage would remain exactly the same.

> 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.
>

I totally agree with separating all of that stuff out into a separate 
block of code/functionality/API.  I actually see those all as being 
quite different in usage from the very simple sequential case.

I'm not sure I agree with resetting to a default color.  What if I want 
to write to the stream without altering the terminal's graphics settings?

(IMO those terminal graphics attributes are user data, and user data is 
always sacred.)

> 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

Ah, maybe it's preference.  I'd probably do both nesting and not-nesting 
variants.  I always /hated/ being /forced/ to use the modal 
(non-nesting) idea of changing THE color.  Instead, I see it very easily 
as a stack: push and pop the colors.  Otherwise I start writing 
"original format and then %Cred this text is red and then back to the 
%C. .. ... " FFFFFFFffff nooo!  what do I do to get back to the original 
formatting if I don't know what it is?!?!  Maybe I'm drainbamaged, but 
stuff like that will drive me nuts and leave me in mental lockout for a 
number of minutes.

Care to share some examples of the things that frustrate you?

I would prefer that any unclosed/unmatched nesting formatters would be 
automatically closed at the end of the format string.  If only nesting 
formatters are used, it would be least surprising to me if the formatter 
just didn't change the terminal's original settings at all:

// Terminal is currently set to bold-green.
writefln("%Cred(But this text will be red.");
writefln("And this text will be bold-green.");

If I used a non-nesting variant at toplevel and change the current mode, 
then I would expect /that/ to alter the terminal's original settings and 
leave it in a different state than from before the formatted write:

// Terminal is currently set to bold-green.
writefln("%Cred(But this text will be red.");
writefln("And this text will be bold-green.");
writefln("Still bold-green, until %Cblu hey, it's blue now.");
// Terminal is currently set to blue.