[RFC] ColorD

[1100110]

On Sun, 21 Oct 2012 17:32:41 -0500, Chad J  
<chadjoan at __spam.is.bad__gmail.com.is.bad__gmail.com.com> wrote:

> 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 ;)

Actually, IIRC, You can version it to link with ncurses or pdcurses if  
available.
The interface to pdcurses and ncurses is the same, or simply similar  
enough that it works.

I agree color is an important bit to not forget.
-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/