[RFC] ColorD

[Chad J]

On 10/21/2012 06:11 PM, Jens Mueller wrote:
> Chad J wrote:
>> On 10/21/2012 05:01 PM, Jens Mueller wrote:
>>
>> It seems to have a hard ncurses/termcap/etc dependency.
>
> Yes. I think you cannot make it portable without. Please proof me wrong
> and I'll fix this.
>

Well, traditionally it's done with automake/autoconf.  You'd end up with 
preprocessor defines that tell you whether the lib has been statically 
linked or not.  This isn't available here because Phobos doesn't use 
these as a build system and I hope it never does.

>> I'll admit when I started trying to work on doing this thing, I
>> never got anything onto the screen.  What stopped me was that I
>> couldn't figure out how to detect ncurses/termcap/etc.  I was going
>> to shoot for Phobos inclusion and making Phobos always link with
>> ncurses seems like a bad idea.
>
> Dependence on Phobos is bad. If you can detect whether a terminal is
> ANSI compatible then this mode should be default. But I don't know how
> to detect this.
>

Wrong direction on the dependency.  I wouldn't expect Terminal 
coloring/detection to rely on Phobos.  I'd expect it to be one of the 
lower-level modules built into Phobos.

>> Ultimately I expect it to work with writeln or writefln to make it
>> discoverable and easy to work with.
>
> One could try this. At least for Linux. You just have to add the
> appropriate escape sequences. But this won't work on Windows.
>

I remember having a plan for this.  See below.

>> Back then I did design a format spec for introducing colors into
>> format strings:
>> www.chadjoan.com/d/dmd.2.058/html/d/phobos/std_format.html
>
> I doubt that the Phobos maintainers will accept this. This is very
> invasive.

Hmmm, depends what is meant by invasive.

I feel it's the only way to have discoverable and concise syntax.  I'd 
be pretty disappointed if they didn't, regardless of who submits the 
pull request.

I remember it being possible in Phobos to determine the destination of 
the format operation.  If the destination is a string in memory, then no 
color formatting would be applied.  If the destination is a Linux 
terminal of some kind, then some ncurses terminal info would be looked 
up (possible a cached lookup) and escape sequences generated based on 
that.  If the destination is a Windows terminal, then these approaches 
can be considered:
(1) Split the formatted text up on the color format boundaries.  Send 
the slices into the stream one by one, calling the necessary WinAPI 
color formatting functions inbetween.  I think this might not have been 
possible with Phobos' architecture.
(2) Insert ANSI escape sequences into the text.  The I/O code for 
Windows would then have to intercept these and convert them into the 
appropriate WinAPI calls.  I think this was possible, and even 
distinguishable from the case of writing to a string in memory.

If the invasiveness worry comes from the possibility of dumping escape 
sequences into non-terminal destinations, then I hope the above wall of 
text can alleviate that concern.

> I added writecf, writec, etc. with additional arguments.
> writec(Color.red, "some text")
> or
> writecf(Color.red, "%s", "some text")
> This is fine I think. But better options may be worth investigating.
>
> Jens

I really think this should be in Phobos.  If it doesn't go into Phobos, 
then people will write crappy terminal apps with no color.  If it does 
go into Phobos, then the better devs will see the opportunity and use 
it.  Something 3rd party is much less discoverable and won't have nearly 
as much impact.  The use case is almost all CLI apps, so it's not like 
an uncommon corner-case or something.

I run a Gentoo system where things are configured to use color output 
wherever possible.  The portage devs went through all of the necessary 
contortions to get Python to output colored text, somehow.  I feel the 
end result is indispensable.  Color is an extremely useful tool for 
making sure that the user doesn't overlook important bits while scanning 
text.  Outside of Gentoo, I find this most notable in grep: uncolored 
grep output is just awful, but the coloring makes it possible to easily 
identify why the regular expression behaved the way it did.

I look forward to a better CLI ecosystem where highly reliable D 
programs are written quickly and write beautiful colored output ;)