[RFC] ColorD
1100110
0b1100110 at gmail.com
Sun Oct 21 17:56:33 PDT 2012
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/
More information about the Digitalmars-d
mailing list