How about colors and terminal graphics in std.format?

[H. S. Teoh]

On Mon, Mar 12, 2012 at 10:51:08AM +0100, Jacob Carlborg wrote:
> On 2012-03-12 03:16, Chad J wrote:
> >I remember doing colored terminal output in Python. It was pretty
> >nifty, and allows for some slick CLI design. I think D can do better
> >by putting it in the standard library.
> >
> >I was thinking something along the lines of this:
> >http://www.chadjoan.com/d/dmd.2.058/html/d/phobos/std_format.html
> >
> >I figure it would probably be easy to get some of the basics down.
> >More advanced stuff would probably involve messing with terminfo or
> ><term.h>.  Windows' (terribly bad) command prompt can have some of
> >these capabilities implemented too, but in a roundabout way because
> >Windows defines API functions that need to be called to affect
> >terminal graphics and coloring. I figure that would require the help
> >of the I/O routines if I were to work on that.
> >
> >If there's interest, I might take a stab at it.
> >
> >So, would this sort of thing make it in?
> 
> I think it would nice to have, but not in std.format. std.terminal or
> similar would be better.
[...]

+1.

It's better not to pollute std.format with stuff that, strictly
speaking, isn't related to formatting per se, but is tied to a
particular output medium.  This is proven by the fact that the
translation of color escapes only makes sense w.r.t. a particular
terminal, so you'll get garbage if you call std.format on the string,
save it to file, say, then load it later and output it to a possibly
different terminal type.

So what you *really* want is to translate these escape sequences *at
output time*, not at string formatting time. If we do it that way, we
can have the nicer behaviour that these escapes will work on any
terminal and can be freely moved around from terminal to terminal,
because they are only interpreted at the instant when they are actually
being output to that terminal.


T

-- 
All problems are easy in retrospect.