On Monday, 12 March 2012 at 03:27:41 UTC, Damian Ziemba wrote:
> On Monday, 12 March 2012 at 02:52:15 UTC, Andrei Alexandrescu wrote:
>> On 3/11/12 9:16 PM, 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 don't know, seems interesting but I wonder how portable that could be. Probably I'd define a more general means a la %q to mean "send a control sequence" and then would define control sequences as functions or constants.
>>
>>> Oh, on an unrelated note, Phobos' documentation make target is quite
>>> broken:
>>> blahblah/dmd.git/src/phobos $ make -fposix.mak html
>>> make: *** No rule to make target `../web/phobos-prerelease/index.html',
>>> needed by `html'. Stop.
>>>
>>> I examined the makefile and concocted this line of bash that constructs
>>> my desired html file:
>>> dmd -m32 -d -c -o- -version=StdDdoc -I../druntime/import std/format.d
>>> std.ddoc -Dfstd_format.html
>>> and copied std.ddoc from a release version of dmd (it's in src/phobos).
>>
>> Since recently the Phobos doc build is meant to be driven from the site build. I'll fix the standalone thing because it's useful too, just I don't know when.
>>
>>
>>
>> Andrei
>
> It could work.
> In my small framework I use version blocks and I use ansi escape sequences for posix and SetConsoleTextAttribute for windoze.
>
> Ofcourse there would be a need to create unified enumeration with colors as they differ on those platforms too.
>
>
>                 public enum Font
> 		{
> 			Normal = 0,
> 			Underline = 0x8000,
> 			Reverse   = 0x4000,
> 		}
> 		
> 		public enum Color
> 		{
> 			Default = 0x0000,
> 			Blue  = 0x0001,
> 			Green = 0x0002,
> 			Aqua  = 0x0003,
> 			Red   = 0x0004,
> 			Purple= 0x0005,
> 			Yellow= 0x0006,
> 			Gray  = 0x0008,
> 			LightBlue  = 0x0009,
> 			LightGreen = 0x000A,
> 			LightAqua  = 0x000B,
> 			LightRed   = 0x000C,
> 			LightPurple= 0x000D,
> 		}
>
> Those are colors and font-attributes that I found to match both Windows and Posix

Those numbers are for Windows btw :p

On 03/11/2012 11:27 PM, Damian Ziemba wrote:
> On Monday, 12 March 2012 at 02:52:15 UTC, Andrei Alexandrescu wrote:
>> On 3/11/12 9:16 PM, 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.
>>>
>>> ...
>>>
>>> So, would this sort of thing make it in?
>>
>> I don't know, seems interesting but I wonder how portable that could
>> be. Probably I'd define a more general means a la %q to mean "send a
>> control sequence" and then would define control sequences as functions
>> or constants.
>>
>>> ...
>>
>> Andrei
>
> It could work.
> In my small framework I use version blocks and I use ansi escape
> sequences for posix and SetConsoleTextAttribute for windoze.
>
> Ofcourse there would be a need to create unified enumeration with colors
> as they differ on those platforms too.
>

Good catch.

>
> public enum Font
> {
> Normal = 0,
> Underline = 0x8000,
> Reverse = 0x4000,
> }
>
> public enum Color
> {
> Default = 0x0000,
> Blue = 0x0001,
> Green = 0x0002,
> Aqua = 0x0003,
> Red = 0x0004,
> Purple= 0x0005,
> Yellow= 0x0006,
> Gray = 0x0008,
> LightBlue = 0x0009,
> LightGreen = 0x000A,
> LightAqua = 0x000B,
> LightRed = 0x000C,
> LightPurple= 0x000D,
> }
>
> Those are colors and font-attributes that I found to match both Windows
> and Posix
>

If you can show me you're work and it's licensed in a way that I can use it in Phobos, then I'll happily try to make use of it.  It'd be much appreciated.

On Monday, 12 March 2012 at 03:30:09 UTC, Damian Ziemba wrote:
> Those numbers are for Windows btw :p

It is also the way the VGA hardware works... and it
is actually a really simple bitfield for a four bit
color.

The attributes are a ubyte like so:

back_fore
lrgb_lrgb


where l is a bit meaning "light" or bright.

That's where the colors come from:

blue = 0001 == 0x01
green = 0010 == 0x02
red = 0100 == 0x04

combine them. yellow is red + green

yellow = 0110 == 0x06

Bright purple is bright | red | blue:

1101 == 13 == 0x0d


On the vga hardware, a "light background" meant
blink.

On 12 March 2012 16:15, Chad J <chadjoan@__spam.is.bad__gmail.com> wrote:
> On 03/11/2012 10:52 PM, Andrei Alexandrescu wrote:
>>
>> On 3/11/12 9:16 PM, 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
>>>
>>> ...
>>>
>>>
>>> If there's interest, I might take a stab at it.
>>>
>>> So, would this sort of thing make it in?
>>
>>
>> I don't know, seems interesting but I wonder how portable that could be. Probably I'd define a more general means a la %q to mean "send a control sequence" and then would define control sequences as functions or constants.
>>
>
> My intent is to make it easy to use.  If it's not easy to use, I wouldn't use it.  If someone wants low-level, they can help themselves to curses.  It should be possible to do this reasonably portably.  I know Python was able to do this well on both my Linux install and my Windows install.
>
> If other OSes have known issues, it can be solved by using either better feature detection or simply version()'ing out the code that inserts control sequences on those OSes.
>
> My plan would be something like this:
>
> version(Windows)
> {
>        // There is only one possible way to do this:
>        // Call WinAPI functions.
> }
> else version(Posix)
> {
>        Look for the terminfo database.
>        Check $TERMINFO,
>                then ~/.terminfo,
>                then /usr/share/terminfo,
>                then /usr/lib/terminfo,
>                then /etc/terminfo,
>                then give up if not found.
>        if ( terminfo found )
>        {
>                query terminfo for terminal capabilities and sequences
>                emit sequences as appropriate
>        }
>        else
>        {
>                Don't output control sequences.
>        }
>
>        // Using <term.h> might be easier,
>        //   but I don't know how portable it is. :/
> }
> else
> {
>        // Don't output control sequences.
>
> }
>
>
>>> Oh, on an unrelated note, Phobos' documentation make target is quite
>>> broken:
>>> blahblah/dmd.git/src/phobos $ make -fposix.mak html
>>> make: *** No rule to make target `../web/phobos-prerelease/index.html',
>>> needed by `html'. Stop.
>>>
>>> I examined the makefile and concocted this line of bash that constructs
>>> my desired html file:
>>> dmd -m32 -d -c -o- -version=StdDdoc -I../druntime/import std/format.d
>>> std.ddoc -Dfstd_format.html
>>> and copied std.ddoc from a release version of dmd (it's in src/phobos).
>>
>>
>> Since recently the Phobos doc build is meant to be driven from the site build. I'll fix the standalone thing because it's useful too, just I don't know when.
>>
>>
>>
>> Andrei
>
>
> Alright, thanks!
>
> Btw, did we ever get a git repo that includes the release files for D and tracks dmd/druntime/phobos as sub-repositories at the correct paths?  Such a thing would be really useful for me if I want to feel like working on this stuff very much.  I don't think I have the ability to update DMD documentation from git right now.

Another thing is that on UNIX there technically isn't a standard way to put out colors. Ideally you'd want to interrogate termcap in those instances. This also means that you output the correct sequences when terminals don't support color, i.e., nothing. Terminals are strange, complicated beasts.

--
James Miller

On Monday, 12 March 2012 at 03:32:26 UTC, Chad J wrote:
> On 03/11/2012 11:27 PM, Damian Ziemba wrote:
>> On Monday, 12 March 2012 at 02:52:15 UTC, Andrei Alexandrescu wrote:
>>> On 3/11/12 9:16 PM, 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.
>>>>
>>>> ...
>>>>
>>>> So, would this sort of thing make it in?
>>>
>>> I don't know, seems interesting but I wonder how portable that could
>>> be. Probably I'd define a more general means a la %q to mean "send a
>>> control sequence" and then would define control sequences as functions
>>> or constants.
>>>
>>>> ...
>>>
>>> Andrei
>>
>> It could work.
>> In my small framework I use version blocks and I use ansi escape
>> sequences for posix and SetConsoleTextAttribute for windoze.
>>
>> Ofcourse there would be a need to create unified enumeration with colors
>> as they differ on those platforms too.
>>
>
> Good catch.
>
>>
>> public enum Font
>> {
>> Normal = 0,
>> Underline = 0x8000,
>> Reverse = 0x4000,
>> }
>>
>> public enum Color
>> {
>> Default = 0x0000,
>> Blue = 0x0001,
>> Green = 0x0002,
>> Aqua = 0x0003,
>> Red = 0x0004,
>> Purple= 0x0005,
>> Yellow= 0x0006,
>> Gray = 0x0008,
>> LightBlue = 0x0009,
>> LightGreen = 0x000A,
>> LightAqua = 0x000B,
>> LightRed = 0x000C,
>> LightPurple= 0x000D,
>> }
>>
>> Those are colors and font-attributes that I found to match both Windows
>> and Posix
>>
>
> If you can show me you're work and it's licensed in a way that I can use it in Phobos, then I'll happily try to make use of it.  It'd be much appreciated.

Sure, give me some time and I will prepare code.
Framework is BSD licensed but I can relicense it to whatever you want.

On Monday, 12 March 2012 at 03:28:40 UTC, Chad J wrote:
> I was kind of intending to /not/ do that, for exactly the reasons you mention.  ASCII escape sequences should work anyways.  I don't think anyone will panic if I waste a byte or two for every 3+ on fairly rare coloring/gfx operations.  And then there's always terminfo in the long picture.

If it is done on the output part, that's ok. Really,
I guess it is ok by me as long as the documentation
warns about not using it in another context.

BTW, also, if stdout is not a terminal on unix, I
don't think you should output the colors (at least
not by default). Most unix apps don't put color
sequences out to pipes, etc.

I'm not sure how to best do this in std.format; this
kind of decision seems like it belongs in std.stdio.

On Sun, Mar 11, 2012 at 10:16:06PM -0400, Chad J wrote: [...]
> Oh, on an unrelated note, Phobos' documentation make target is quite broken:
> blahblah/dmd.git/src/phobos $ make -fposix.mak html
> make: *** No rule to make target
> `../web/phobos-prerelease/index.html', needed by `html'.  Stop.
[...]

If you also checkout "d-programming-language.org" (the website code) from git and put it at the same level as the phobos subdir, then the build will work.


T

-- 
Живёшь только однажды.

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.

-- 
/Jacob Carlborg

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.

On Monday, 12 March 2012 at 03:32:26 UTC, Chad J wrote:
> On 03/11/2012 11:27 PM, Damian Ziemba wrote:
>> On Monday, 12 March 2012 at 02:52:15 UTC, Andrei Alexandrescu wrote:
>>> On 3/11/12 9:16 PM, 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.
>>>>
>>>> ...
>>>>
>>>> So, would this sort of thing make it in?
>>>
>>> I don't know, seems interesting but I wonder how portable that could
>>> be. Probably I'd define a more general means a la %q to mean "send a
>>> control sequence" and then would define control sequences as functions
>>> or constants.
>>>
>>>> ...
>>>
>>> Andrei
>>
>> It could work.
>> In my small framework I use version blocks and I use ansi escape
>> sequences for posix and SetConsoleTextAttribute for windoze.
>>
>> Ofcourse there would be a need to create unified enumeration with colors
>> as they differ on those platforms too.
>>
>
> Good catch.
>
>>
>> public enum Font
>> {
>> Normal = 0,
>> Underline = 0x8000,
>> Reverse = 0x4000,
>> }
>>
>> public enum Color
>> {
>> Default = 0x0000,
>> Blue = 0x0001,
>> Green = 0x0002,
>> Aqua = 0x0003,
>> Red = 0x0004,
>> Purple= 0x0005,
>> Yellow= 0x0006,
>> Gray = 0x0008,
>> LightBlue = 0x0009,
>> LightGreen = 0x000A,
>> LightAqua = 0x000B,
>> LightRed = 0x000C,
>> LightPurple= 0x000D,
>> }
>>
>> Those are colors and font-attributes that I found to match both Windows
>> and Posix
>>
>
> If you can show me you're work and it's licensed in a way that I can use it in Phobos, then I'll happily try to make use of it.  It'd be much appreciated.

Hey Chad.

Sorry for delay, been a bit busy.
Here it is: https://gist.github.com/2025473
I hope it can help you somehow.
(There is place for improvments I know but I used it mostly for debbuging stuff ;))

And yea, I think like others that it should have its own module like std.terminal/std.console or maybe somekind of spot in std.stdio.

Best Regards,
Damian Ziemba