www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - How about colors and terminal graphics in std.format?

reply Chad J <chadjoan __spam.is.bad__gmail.com> writes:
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?



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).
Mar 11 2012
next sibling parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 12-03-2012 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.


There is!


 So, would this sort of thing make it in?



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



-- 
- Alex
Mar 11 2012
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Mar 11 2012
next sibling parent "Damian Ziemba" <spam dzfl.pl> writes:
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


Some basic stuff like Colors can be portable.
I can share my work if somebody is interested.

Best regards,
Damian Ziemba
Mar 11 2012
prev sibling next sibling parent =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
On 12-03-2012 03:52, 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.


It works for .NET: 
http://msdn.microsoft.com/en-us/library/system.consolecolor.aspx

This is implemented across all platforms in Mono.


 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



-- 
- Alex
Mar 11 2012
prev sibling next sibling parent reply Chad J <chadjoan __spam.is.bad__gmail.com> writes:
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.
Mar 11 2012
parent James Miller <james aatch.net> writes:
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 puttin=






g

 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. =C2=A0If it's not easy to use, I wou=


ldn't

 use it. =C2=A0If someone wants low-level, they can help themselves to cur=


ses. =C2=A0It

 should be possible to do this reasonably portably. =C2=A0I know Python wa=


s 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 contr=


ol

 sequences on those OSes.

 My plan would be something like this:

 version(Windows)
 {
 =C2=A0 =C2=A0 =C2=A0 =C2=A0// There is only one possible way to do this:
 =C2=A0 =C2=A0 =C2=A0 =C2=A0// Call WinAPI functions.
 }
 else version(Posix)
 {
 =C2=A0 =C2=A0 =C2=A0 =C2=A0Look for the terminfo database.
 =C2=A0 =C2=A0 =C2=A0 =C2=A0Check $TERMINFO,
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0then ~/.terminfo,
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0then /usr/share/te=


rminfo,

 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0then /usr/lib/term=


info,

 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0then /etc/terminfo=


,

 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0then give up if no=


t found.

 =C2=A0 =C2=A0 =C2=A0 =C2=A0if ( terminfo found )
 =C2=A0 =C2=A0 =C2=A0 =C2=A0{
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0query terminfo for=


 terminal capabilities and sequences

 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0emit sequences as =


appropriate

 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
 =C2=A0 =C2=A0 =C2=A0 =C2=A0else
 =C2=A0 =C2=A0 =C2=A0 =C2=A0{
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Don't output contr=


ol sequences.

 =C2=A0 =C2=A0 =C2=A0 =C2=A0}

 =C2=A0 =C2=A0 =C2=A0 =C2=A0// Using <term.h> might be easier,
 =C2=A0 =C2=A0 =C2=A0 =C2=A0// =C2=A0 but I don't know how portable it is.=


 :/

 }
 else
 {
 =C2=A0 =C2=A0 =C2=A0 =C2=A0// 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=3DStdDdoc -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? =C2=


=A0Such a

 thing would be really useful for me if I want to feel like working on thi=


s

 stuff very much. =C2=A0I 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
Mar 11 2012
prev sibling parent reply "Damian Ziemba" <razriel dzfl.pl> writes:
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
Mar 11 2012
next sibling parent reply "Damian Ziemba" <spam dzfl.pl> writes:
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
Mar 11 2012
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
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.
Mar 11 2012
prev sibling parent reply Chad J <chadjoan __spam.is.bad__gmail.com> writes:
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.
Mar 11 2012
next sibling parent "Damian Ziemba" <spam dzfl.pl> writes:
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.
Mar 11 2012
prev sibling parent reply "Damian Ziemba" <spam dzfl.pl> writes:
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
Mar 12 2012
next sibling parent reply Kevin Cox <kevincox.ca gmail.com> writes:
On Mar 12, 2012 7:55 PM, "Damian Ziemba" <spam dzfl.pl> wrote

 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.

Python has a great lib for this.  I can't remember what package it is in
but it has things like isTty() and all of the colors as well ad querying
for different color support.  For a name may I recommend std.term.
Mar 12 2012
parent "Damian Ziemba" <spam dzfl.pl> writes:
On Tuesday, 13 March 2012 at 00:24:58 UTC, Kevin Cox wrote:

 On Mar 12, 2012 7:55 PM, "Damian Ziemba" <spam dzfl.pl> wrote

 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.

 Python has a great lib for this.  I can't remember what package 
 it is in
 but it has things like isTty() and all of the colors as well ad 
 querying
 for different color support.  For a name may I recommend 
 std.term.


Urwid?

Well there are Ncurses bindings lying around, but I guess the 
point is to get something rather simple. Ofcourse porting for 
example Urwid from Python to D would be possible but I am not 
sure if there is a point in doing so.

In my framework I've added only stuff that I missed from MS Class 
Library, and actually were useful, like Console.ReadKey or 
Console.ForegroundColor.

I think that Chad idea was to provide something simple like that.
Mar 12 2012
prev sibling parent Chad J <chadjoan __spam.is.bad__gmail.com> writes:
On 03/12/2012 07:51 PM, Damian Ziemba wrote:

 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


Hey, np about the delay.  I'm not going to get to working on this stuff 
that soon anyways.

Thanks for the code!
Mar 12 2012
prev sibling next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
One concern I have with this is format() creates a
string, which isn't necessarily output; color is
a thing of output.

The unix implementation will use the ansi escape
sequences, surely, which isn't correct almost
anywhere else.

Of course, you could choose to not use these
special specifiers, and put a note in the
documentation explaining what it is, so
not a big deal... but I just think it is
somewhat wrong to put special control
sequences in the middle of a regular string
that might be used anywhere.
Mar 11 2012
parent reply Chad J <chadjoan __spam.is.bad__gmail.com> writes:
On 03/11/2012 11:05 PM, Adam D. Ruppe wrote:

 One concern I have with this is format() creates a
 string, which isn't necessarily output; color is
 a thing of output.

 The unix implementation will use the ansi escape
 sequences, surely, which isn't correct almost
 anywhere else.


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.


 Of course, you could choose to not use these
 special specifiers, and put a note in the
 documentation explaining what it is, so
 not a big deal... but I just think it is
 somewhat wrong to put special control
 sequences in the middle of a regular string
 that might be used anywhere.


The primary intent of this is to be used with writefln or any other 
routines that will be writing to the terminal.

That this can emit escape sequences to other targets is a consequence of 
std.format being abstracted from the I/O routines.  I think it is fine. 
  I doubt people will put color formatting into strings that they know 
will not end up on a terminal.  And if they don't realize that 
limitation, then perhaps I should change the way it's documented so that 
it's /really obvious/ that the resulting strings will only colorize on 
process's attached terminal, and produce gobbledygook otherwise.
Mar 11 2012
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
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.
Mar 11 2012
prev sibling next sibling parent Mantis <mail.mantis.88 gmail.com> writes:
12.03.2012 4:16, Chad J пишет:

 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?



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


This is not exactly what you mean, but related. There are some graphics 
manipulation functions in dmc runtime: http://digitalmars.com/rtl/disp.html
These are accessible from D, but there's no header, so you'll need to 
declare them manually in your program.
Here's a translated example of outputting a red text:

//
extern( C ) void disp_open();
extern( C ) int disp_getattr();
extern( C ) void disp_setattr( int attr );
extern( C ) int disp_printf( char * format, ... );
extern( C ) void disp_close();

int main() {
int attr;

disp_open();
attr = disp_getattr();
disp_setattr(0x7C);
disp_printf( "hello world!\0".dup.ptr );
disp_setattr(attr);
disp_printf( "\r\n\0".dup.ptr );
disp_close();

return 0;
}
//
Mar 11 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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

-- 
Живёшь только однажды.
Mar 11 2012
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
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
Mar 12 2012
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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.
Mar 12 2012
parent reply Chad J <chadjoan __spam.is.bad__gmail.com> writes:
On 03/12/2012 11:02 AM, H. S. Teoh wrote:

 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



I never felt it would go into std.terminal because I have a fairly 
narrow purpose in mind.  If I wanted to do anything a bit fancier, I 
would be all about making std.terminal.  But currently I feel that this 
would be orthogonal to such a module.  This is very lightweight on the 
learning side, while std.terminal would include code to handle multiple 
terminals and interactivity: it would be much heavier and a bigger 
mental investment from the user.


Anyhow, here are my objectives:

What I really want is to have an /easy/ way to do color formatting.  I 
want to be able to write this:

writefln("%Cred(Red text:%) Normal text.");

The syntax should be similar to format strings so that memorization is 
easier due to the extra association, and also so that we don't escapify 
yet another special character: '%' and '\' are already required to be 
written as '%%' and '\\' in various contexts and it would be annoying to 
have yet another one.

I suppose that could be handled output side, but I don't know how I'd 
avoid stuff like this:

writefln("%%Cred(Red text:%%) %d%%%% complete.",percentComplete);

It also made a lot of sense to me that I would find documentation on 
coloring in the place I'd find documentation on formatting.  Maybe this 
isn't what others feel.  Nonetheless, I'm inclined to start from 
intuition and refine if there are objections.

There are probably going to be multiple ways to push things to the 
terminal (maybe in multiple source files too: stdio vs stream?) and it 
should be possible to colorize all of them in a uniform manner. 
Documentation should be easy to find; discovery should be intuitive.


If someone has a good vision that accomplishes these things, then please 
do share.
Mar 12 2012
parent reply James Miller <james aatch.net> writes:
On 13 March 2012 15:20, Chad J <chadjoan __spam.is.bad__gmail.com> wrote:

 On 03/12/2012 11:02 AM, H. S. Teoh wrote:

 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>. =C2=A0Windows' (terribly bad) command prompt can have some o=








f

 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. =C2=A0This 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



 I never felt it would go into std.terminal because I have a fairly narrow
 purpose in mind. =C2=A0If I wanted to do anything a bit fancier, I would =


be all

 about making std.terminal. =C2=A0But currently I feel that this would be
 orthogonal to such a module. =C2=A0This is very lightweight on the learni=


ng side,

 while std.terminal would include code to handle multiple terminals and
 interactivity: it would be much heavier and a bigger mental investment fr=


om

 the user.


 Anyhow, here are my objectives:

 What I really want is to have an /easy/ way to do color formatting. =C2=


=A0I want

 to be able to write this:

 writefln("%Cred(Red text:%) Normal text.");

 The syntax should be similar to format strings so that memorization is
 easier due to the extra association, and also so that we don't escapify y=


et

 another special character: '%' and '\' are already required to be written=


 as

 '%%' and '\\' in various contexts and it would be annoying to have yet
 another one.

 I suppose that could be handled output side, but I don't know how I'd avo=


id

 stuff like this:

 writefln("%%Cred(Red text:%%) %d%%%% complete.",percentComplete);

 It also made a lot of sense to me that I would find documentation on
 coloring in the place I'd find documentation on formatting. =C2=A0Maybe t=


his

 isn't what others feel. =C2=A0Nonetheless, I'm inclined to start from int=


uition

 and refine if there are objections.

 There are probably going to be multiple ways to push things to the termin=


al

 (maybe in multiple source files too: stdio vs stream?) and it should be
 possible to colorize all of them in a uniform manner. Documentation shoul=


d

 be easy to find; discovery should be intuitive.


 If someone has a good vision that accomplishes these things, then please =


do

 share.


I think the problem with putting it into formatting is that it is
inherently not output. IOW formatting should go anywhere, but colored
output is terminal-only.

Also, there are differences between terminals and all sorts of crap
that just make this harder to do "simply". However, there's no reason
why there cant be an easy way to colorize output in std.terminal (or
whatever), that are basically just modified writef(ln) calls
(colorWritef?) that only output to stdout (and maybe stderr). I think
this would be a good way around it, because then everything that is
terminal-specific is kept in one place, and you don't get mistakes
like outputting color to a file because you did the wrong sequence, or
forgot to check that stdout is a terminal and all that.

--
James Miller
Mar 12 2012
parent reply Chad J <chadjoan __spam.is.bad__gmail.com> writes:
On 03/12/2012 10:37 PM, James Miller wrote:

 I think the problem with putting it into formatting is that it is
 inherently not output. IOW formatting should go anywhere, but colored
 output is terminal-only.

 Also, there are differences between terminals and all sorts of crap
 that just make this harder to do "simply". However, there's no reason
 why there cant be an easy way to colorize output in std.terminal (or
 whatever), that are basically just modified writef(ln) calls
 (colorWritef?) that only output to stdout (and maybe stderr). I think
 this would be a good way around it, because then everything that is
 terminal-specific is kept in one place, and you don't get mistakes
 like outputting color to a file because you did the wrong sequence, or
 forgot to check that stdout is a terminal and all that.

 --
 James Miller


I do want to be able to format things besides color with the color 
formatting function.  Maybe I can pick out the color format specifiers 
first and then pass the rest to format.  It'd be a shame to reimplement 
format.

At that point it would be cool if thrown exceptions and the like could 
do color formatting, and also know when to strip it out when writing to 
log files and such.  I don't know how difficult or practical it would 
be, but I think that stack traces with color highlights would be 
awesome.  It's pretty in-your-face user experience-wise too; might be 
good PR for D.

So then, now for the fun part.  What to name this function?

zoosmellPooplord(ln)("%Cred(Text.%)");
Mar 12 2012
next sibling parent Chad J <chadjoan __spam.is.bad__gmail.com> writes:
On 03/12/2012 11:58 PM, Chad J wrote:

 On 03/12/2012 10:37 PM, James Miller wrote:

 I think the problem with putting it into formatting is that it is
 inherently not output. IOW formatting should go anywhere, but colored
 output is terminal-only.

 Also, there are differences between terminals and all sorts of crap
 that just make this harder to do "simply". However, there's no reason
 why there cant be an easy way to colorize output in std.terminal (or
 whatever), that are basically just modified writef(ln) calls
 (colorWritef?) that only output to stdout (and maybe stderr). I think
 this would be a good way around it, because then everything that is
 terminal-specific is kept in one place, and you don't get mistakes
 like outputting color to a file because you did the wrong sequence, or
 forgot to check that stdout is a terminal and all that.

 --
 James Miller


 I do want to be able to format things besides color with the color
 formatting function. Maybe I can pick out the color format specifiers
 first and then pass the rest to format. It'd be a shame to reimplement
 format.

 At that point it would be cool if thrown exceptions and the like could
 do color formatting, and also know when to strip it out when writing to
 log files and such. I don't know how difficult or practical it would be,
 but I think that stack traces with color highlights would be awesome.
 It's pretty in-your-face user experience-wise too; might be good PR for D.

 So then, now for the fun part. What to name this function?

 zoosmellPooplord(ln)("%Cred(Text.%)");


Actually, wait a sec.

So I don't do it in format.

But I can create a color-format function that takes a terminal spec does 
some color formats and optionally some std.format formats as well.  It 
would output a string with the correct escape sequences (hey, you never 
know when you might want to inspect the escape sequences it produces).

So we define
string std.terminal.colorFormat(TerminalSpec spec, string fmtstr);
and std.format remains untouched.
And then...

Why not have writef(ln) use it?  writef(ln) functions know what they are 
attached to right?

They can just strip the formatting out for non-terminal destinations.

I would much prefer this.  I don't like the idea of having different 
writefln and termfln when they both do the same damn thing sans some 
simple coloring functionality.
Mar 12 2012
prev sibling next sibling parent reply James Miller <james aatch.net> writes:
On 13 March 2012 16:58, Chad J <chadjoan __spam.is.bad__gmail.com> wrote:

 On 03/12/2012 10:37 PM, James Miller wrote:

 I think the problem with putting it into formatting is that it is
 inherently not output. IOW formatting should go anywhere, but colored
 output is terminal-only.

 Also, there are differences between terminals and all sorts of crap
 that just make this harder to do "simply". However, there's no reason
 why there cant be an easy way to colorize output in std.terminal (or
 whatever), that are basically just modified writef(ln) calls
 (colorWritef?) that only output to stdout (and maybe stderr). I think
 this would be a good way around it, because then everything that is
 terminal-specific is kept in one place, and you don't get mistakes
 like outputting color to a file because you did the wrong sequence, or
 forgot to check that stdout is a terminal and all that.

 --
 James Miller



 I do want to be able to format things besides color with the color
 formatting function. =C2=A0Maybe I can pick out the color format specifie=


rs first

 and then pass the rest to format. =C2=A0It'd be a shame to reimplement fo=


rmat.

 At that point it would be cool if thrown exceptions and the like could do
 color formatting, and also know when to strip it out when writing to log
 files and such. =C2=A0I don't know how difficult or practical it would be=


, but I

 think that stack traces with color highlights would be awesome. =C2=A0It'=


s pretty

 in-your-face user experience-wise too; might be good PR for D.

 So then, now for the fun part. =C2=A0What to name this function?

 zoosmellPooplord(ln)("%Cred(Text.%)");


I wasn't suggesting to actually re-implement format, actually my idea
was similar to yours in that it would wrap over writef(ln). But doing
it this way, rather than extending writef, means that you can check
for output conditions first. It also allows people to realise that the
function they are reading /isn't/ just a bog-standard writefln, and
should be parsed (mentally) differently.

However, I think that any more than just sequential output should
probably have its own set of functions, so a clearLine function,
clearScreen function, setColor functions and all that. This also
suggests that a color-writef should reset to a "default" color at the
end of output, which makes sense.

One thing I would change is to not use syntax quite so similar to
writef though, and also (since it matches better with terminal
operation anyway) not have it wrap, just set the color for the
remaining output, otherwise parsing will be more difficult, since you
have to check for yet more escape sequences, and using it would be
more error-prone. (For an example, vim has some weird escaping rules
for its regex-implementation that catch me out all the time)

--
James Miller
Mar 12 2012
parent reply Chad J <chadjoan __spam.is.bad__gmail.com> writes:
On 03/13/2012 12:15 AM, James Miller wrote:

 On 13 March 2012 16:58, Chad J<chadjoan __spam.is.bad__gmail.com>  wrote:

 On 03/12/2012 10:37 PM, James Miller wrote:

 I think the problem with putting it into formatting is that it is
 inherently not output. IOW formatting should go anywhere, but colored
 output is terminal-only.

 Also, there are differences between terminals and all sorts of crap
 that just make this harder to do "simply". However, there's no reason
 why there cant be an easy way to colorize output in std.terminal (or
 whatever), that are basically just modified writef(ln) calls
 (colorWritef?) that only output to stdout (and maybe stderr). I think
 this would be a good way around it, because then everything that is
 terminal-specific is kept in one place, and you don't get mistakes
 like outputting color to a file because you did the wrong sequence, or
 forgot to check that stdout is a terminal and all that.

 --
 James Miller



 I do want to be able to format things besides color with the color
 formatting function.  Maybe I can pick out the color format specifiers first
 and then pass the rest to format.  It'd be a shame to reimplement format.

 At that point it would be cool if thrown exceptions and the like could do
 color formatting, and also know when to strip it out when writing to log
 files and such.  I don't know how difficult or practical it would be, but I
 think that stack traces with color highlights would be awesome.  It's pretty
 in-your-face user experience-wise too; might be good PR for D.

 So then, now for the fun part.  What to name this function?

 zoosmellPooplord(ln)("%Cred(Text.%)");


 I wasn't suggesting to actually re-implement format, actually my idea
 was similar to yours in that it would wrap over writef(ln). But doing
 it this way, rather than extending writef, means that you can check
 for output conditions first. It also allows people to realise that the
 function they are reading /isn't/ just a bog-standard writefln, and
 should be parsed (mentally) differently.


Why?  This would be an addition of features for writef(ln), not an 
alteration.  Existing writef(ln) usage would remain exactly the same.


 However, I think that any more than just sequential output should
 probably have its own set of functions, so a clearLine function,
 clearScreen function, setColor functions and all that. This also
 suggests that a color-writef should reset to a "default" color at the
 end of output, which makes sense.


I totally agree with separating all of that stuff out into a separate 
block of code/functionality/API.  I actually see those all as being 
quite different in usage from the very simple sequential case.

I'm not sure I agree with resetting to a default color.  What if I want 
to write to the stream without altering the terminal's graphics settings?

(IMO those terminal graphics attributes are user data, and user data is 
always sacred.)


 One thing I would change is to not use syntax quite so similar to
 writef though, and also (since it matches better with terminal
 operation anyway) not have it wrap, just set the color for the
 remaining output, otherwise parsing will be more difficult, since you
 have to check for yet more escape sequences, and using it would be
 more error-prone. (For an example, vim has some weird escaping rules
 for its regex-implementation that catch me out all the time)

 --
 James Miller


Ah, maybe it's preference.  I'd probably do both nesting and not-nesting 
variants.  I always /hated/ being /forced/ to use the modal 
(non-nesting) idea of changing THE color.  Instead, I see it very easily 
as a stack: push and pop the colors.  Otherwise I start writing 
"original format and then %Cred this text is red and then back to the 
%C. .. ... " FFFFFFFffff nooo!  what do I do to get back to the original 
formatting if I don't know what it is?!?!  Maybe I'm drainbamaged, but 
stuff like that will drive me nuts and leave me in mental lockout for a 
number of minutes.

Care to share some examples of the things that frustrate you?

I would prefer that any unclosed/unmatched nesting formatters would be 
automatically closed at the end of the format string.  If only nesting 
formatters are used, it would be least surprising to me if the formatter 
just didn't change the terminal's original settings at all:

// Terminal is currently set to bold-green.
writefln("%Cred(But this text will be red.");
writefln("And this text will be bold-green.");

If I used a non-nesting variant at toplevel and change the current mode, 
then I would expect /that/ to alter the terminal's original settings and 
leave it in a different state than from before the formatted write:

// Terminal is currently set to bold-green.
writefln("%Cred(But this text will be red.");
writefln("And this text will be bold-green.");
writefln("Still bold-green, until %Cblu hey, it's blue now.");
// Terminal is currently set to blue.
Mar 12 2012
parent reply James Miller <james aatch.net> writes:
On 13 March 2012 18:24, Chad J <chadjoan __spam.is.bad__gmail.com> wrote:

 I'm not sure I agree with resetting to a default color. =C2=A0What if I w=


ant to

 write to the stream without altering the terminal's graphics settings?


Actually, I meant more to make sure that any output is reset to the
terminal's default. I'm pretty sure there is a way to do this. The
point is that not undoing mode changes is bad form.

Otherwise, I can live with the colourings being nested, but I would
suggest a change in syntax, I understand that yours is mostly just for
show, but using parenthesis will be annoying, I'd probably use braces
('{' and '}') instead, since they are less common.

writefln('%Cred(\(this is in color\))');
 vs
writefln('%Cred{(this is in color)}');

Neither are /that/ pretty, but at least the second one requires less
escaping in the common case.

--
James Miller
Mar 12 2012
parent reply Chad J <chadjoan __spam.is.bad__gmail.com> writes:
On 03/13/2012 01:41 AM, James Miller wrote:

 On 13 March 2012 18:24, Chad J<chadjoan __spam.is.bad__gmail.com>  wrote:

 I'm not sure I agree with resetting to a default color.  What if I want to
 write to the stream without altering the terminal's graphics settings?


 Actually, I meant more to make sure that any output is reset to the
 terminal's default. I'm pretty sure there is a way to do this. The
 point is that not undoing mode changes is bad form.

 Otherwise, I can live with the colourings being nested, but I would
 suggest a change in syntax, I understand that yours is mostly just for
 show, but using parenthesis will be annoying, I'd probably use braces
 ('{' and '}') instead, since they are less common.

 writefln('%Cred(\(this is in color\))');
   vs
 writefln('%Cred{(this is in color)}');

 Neither are /that/ pretty, but at least the second one requires less
 escaping in the common case.

 --
 James Miller


Oh, I see what you mean.

This is why the second paren always had a % before it:

writefln('%Cred((this is in color)%)');

Is this OK?  I know that escaping is still involved, but the text itself 
does not need escaping: only the special closing element does.

I like this constraint because it means that the only character you ever 
have to escape in your normal text is %, which you write by using %% 
instead.
Mar 12 2012
parent James Miller <james aatch.net> writes:
On 13 March 2012 18:50, Chad J <chadjoan __spam.is.bad__gmail.com> wrote:

 On 03/13/2012 01:41 AM, James Miller wrote:

 On 13 March 2012 18:24, Chad J<chadjoan __spam.is.bad__gmail.com> =C2=A0=




wrote:

 I'm not sure I agree with resetting to a default color. =C2=A0What if I=






 want

 to

 write to the stream without altering the terminal's graphics settings?



 Actually, I meant more to make sure that any output is reset to the
 terminal's default. I'm pretty sure there is a way to do this. The
 point is that not undoing mode changes is bad form.

 Otherwise, I can live with the colourings being nested, but I would
 suggest a change in syntax, I understand that yours is mostly just for
 show, but using parenthesis will be annoying, I'd probably use braces
 ('{' and '}') instead, since they are less common.

 writefln('%Cred(\(this is in color\))');
 =C2=A0vs
 writefln('%Cred{(this is in color)}');

 Neither are /that/ pretty, but at least the second one requires less
 escaping in the common case.

 --
 James Miller



 Oh, I see what you mean.

 This is why the second paren always had a % before it:

 writefln('%Cred((this is in color)%)');

 Is this OK? =C2=A0I know that escaping is still involved, but the text it=


self

 does not need escaping: only the special closing element does.

 I like this constraint because it means that the only character you ever
 have to escape in your normal text is %, which you write by using %%
 instead.


That works, and I think it matches zsh's style. I still think that
'{', '}' would be better, but I'm not dead-set on it.

--
James Miller
Mar 12 2012
prev sibling parent Sean Cavanaugh <WorksOnMyMachine gmail.com> writes:
On 3/12/2012 10:58 PM, Chad J wrote:

 On 03/12/2012 10:37 PM, James Miller wrote:

 I do want to be able to format things besides color with the color
 formatting function. Maybe I can pick out the color format specifiers
 first and then pass the rest to format. It'd be a shame to reimplement
 format.


There are something like 4 million UTF characters designated for 
user-defined use.  I had hooked some range of this into RGBA color codes 
for easy rendering text for D3D, as the function needs to parse the 
string to generate texture UVs for the glyphs, and might as well be 
setting some vertex attributes for color along the way etc.
Mar 12 2012
prev sibling parent reply "Christian Manning" <cmanning999 gmail.com> writes:
On Monday, 12 March 2012 at 09:51:08 UTC, 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.


It would be great if an std.terminal contained general stuff for 
manipulating/querying a terminal portably, as well as colour 
output, eg. get terminal size, move cursor around, erase line... 
just things to help with building UIs, progress bars, etc. that 
are easy to use.
Mar 12 2012
next sibling parent reply Chad J <chadjoan __spam.is.bad__gmail.com> writes:
On 03/12/2012 09:36 PM, Christian Manning wrote:

 On Monday, 12 March 2012 at 09:51:08 UTC, Jacob Carlborg wrote:

 I think it would nice to have, but not in std.format. std.terminal or
 similar would be better.


 It would be great if an std.terminal contained general stuff for
 manipulating/querying a terminal portably, as well as colour output, eg.
 get terminal size, move cursor around, erase line... just things to help
 with building UIs, progress bars, etc. that are easy to use.


Although this would be cool, it is out of the scope of what I am willing 
to spend time on.

My intent is to make color output easy.  Handling interactive stuff is a 
completely different beast from the usage standpoint.

I might do it someday if I feel like writing a game using terminal 
graphics, but even then there is no guarantee it would be phobos worthy.
Mar 12 2012
parent reply "Christian Manning" <cmanning999 gmail.com> writes:
On Tuesday, 13 March 2012 at 01:53:11 UTC, Chad J wrote:

 On 03/12/2012 09:36 PM, Christian Manning wrote:

 On Monday, 12 March 2012 at 09:51:08 UTC, Jacob Carlborg wrote:

 I think it would nice to have, but not in std.format. 
 std.terminal or
 similar would be better.


 It would be great if an std.terminal contained general stuff 
 for
 manipulating/querying a terminal portably, as well as colour 
 output, eg.
 get terminal size, move cursor around, erase line... just 
 things to help
 with building UIs, progress bars, etc. that are easy to use.


 Although this would be cool, it is out of the scope of what I 
 am willing to spend time on.


That's fair enough, I was mostly making a point that both things 
are closely related and would make sense in a common module.
Mar 12 2012
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Mar 13, 2012 at 03:02:27AM +0100, Christian Manning wrote:

 On Tuesday, 13 March 2012 at 01:53:11 UTC, Chad J wrote:

On 03/12/2012 09:36 PM, Christian Manning wrote:

On Monday, 12 March 2012 at 09:51:08 UTC, Jacob Carlborg wrote:

I think it would nice to have, but not in std.format.  std.terminal
or similar would be better.


It would be great if an std.terminal contained general stuff for
manipulating/querying a terminal portably, as well as colour output,
eg.  get terminal size, move cursor around, erase line... just
things to help with building UIs, progress bars, etc. that are easy
to use.


Although this would be cool, it is out of the scope of what I am
willing to spend time on.


 
 That's fair enough, I was mostly making a point that both things are
 closely related and would make sense in a common module.


We could start off with said module just doing colors for now, and then
gradually add more stuff to it later.


T

-- 
Ph.D. = Permanent head Damage
Mar 12 2012
prev sibling next sibling parent James Miller <james aatch.net> writes:
On 13 March 2012 15:17, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:

 We could start off with said module just doing colors for now, and then
 gradually add more stuff to it later.


We could end up at a D-flavoured ncurses library!

--
James Miller
Mar 12 2012
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Mar 13, 2012 at 03:17:42PM +1300, James Miller wrote:

 On 13 March 2012 15:17, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:

 We could start off with said module just doing colors for now, and
 then gradually add more stuff to it later.


 
 We could end up at a D-flavoured ncurses library!


[...]

That would be a dream come true for me.

I have to admit that I find the ncurses API quite ugly, and not very
well-designed. It's the curse (pun intended) of inheriting a decades-old
API that was designed back in the days when people didn't know very much
about good API design.


T

-- 
Marketing: the art of convincing people to pay for what they didn't need
before which you can't deliver after.
Mar 12 2012
parent Chad J <chadjoan __spam.is.bad__gmail.com> writes:
On 03/13/2012 01:34 AM, H. S. Teoh wrote:

 On Tue, Mar 13, 2012 at 03:17:42PM +1300, James Miller wrote:

 On 13 March 2012 15:17, H. S. Teoh<hsteoh quickfur.ath.cx>  wrote:

 We could start off with said module just doing colors for now, and
 then gradually add more stuff to it later.


 We could end up at a D-flavoured ncurses library!


 [...]

 That would be a dream come true for me.

 I have to admit that I find the ncurses API quite ugly, and not very
 well-designed. It's the curse (pun intended) of inheriting a decades-old
 API that was designed back in the days when people didn't know very much
 about good API design.


 T


Yes.

Maybe someday...
Mar 12 2012
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-03-13 02:36, Christian Manning wrote:


 It would be great if an std.terminal contained general stuff for
 manipulating/querying a terminal portably, as well as colour output, eg.
 get terminal size, move cursor around, erase line... just things to help
 with building UIs, progress bars, etc. that are easy to use.


I actually have a library for this written in C++, somewhere.

-- 
/Jacob Carlborg
Mar 13 2012
parent reply "Christian Manning" <cmanning999 gmail.com> writes:
On Tuesday, 13 March 2012 at 07:45:19 UTC, Jacob Carlborg wrote:

 On 2012-03-13 02:36, Christian Manning wrote:


 It would be great if an std.terminal contained general stuff 
 for
 manipulating/querying a terminal portably, as well as colour 
 output, eg.
 get terminal size, move cursor around, erase line... just 
 things to help
 with building UIs, progress bars, etc. that are easy to use.


 I actually have a library for this written in C++, somewhere.


Any chance of a release? :)

I'd like to have a stab at porting it to D, when I have time, if 
you aren't already planning to.
Mar 13 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-03-13 13:31, Christian Manning wrote:

 On Tuesday, 13 March 2012 at 07:45:19 UTC, Jacob Carlborg wrote:

 On 2012-03-13 02:36, Christian Manning wrote:


 It would be great if an std.terminal contained general stuff for
 manipulating/querying a terminal portably, as well as colour output, eg.
 get terminal size, move cursor around, erase line... just things to help
 with building UIs, progress bars, etc. that are easy to use.


 I actually have a library for this written in C++, somewhere.


 Any chance of a release? :)

 I'd like to have a stab at porting it to D, when I have time, if you
 aren't already planning to.


I have been thinking about porting it to D from time to time. I can see 
what I can do :)

-- 
/Jacob Carlborg
Mar 13 2012
parent "Christian Manning" <cmanning999 gmail.com> writes:
On Tuesday, 13 March 2012 at 16:05:31 UTC, Jacob Carlborg wrote:

 On 2012-03-13 13:31, Christian Manning wrote:

 On Tuesday, 13 March 2012 at 07:45:19 UTC, Jacob Carlborg 
 wrote:

 On 2012-03-13 02:36, Christian Manning wrote:


 It would be great if an std.terminal contained general stuff 
 for
 manipulating/querying a terminal portably, as well as colour 
 output, eg.
 get terminal size, move cursor around, erase line... just 
 things to help
 with building UIs, progress bars, etc. that are easy to use.


 I actually have a library for this written in C++, somewhere.


 Any chance of a release? :)

 I'd like to have a stab at porting it to D, when I have time, 
 if you
 aren't already planning to.


 I have been thinking about porting it to D from time to time. I 
 can see what I can do :)


Looking forward to it!
Mar 13 2012