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 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
prev sibling next 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
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
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 "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
prev sibling next sibling 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 next sibling 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=



 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=

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

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

 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=

 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=

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

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

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

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

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

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

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

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

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
prev sibling next sibling parent Kevin Cox <kevincox.ca gmail.com> writes:
--0015175d03b2ed148404bb14e271
Content-Type: text/plain; charset=UTF-8

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

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. --0015175d03b2ed148404bb14e271 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <p><br> On Mar 12, 2012 7:55 PM, &quot;Damian Ziemba&quot; &lt;<a href=3D"mailto:sp= am dzfl.pl">spam dzfl.pl</a>&gt; wrote<br> &gt; And yea, I think like others that it should have its own module like s= td.terminal/std.console or maybe somekind of spot in std.stdio.</p> <p>Python has a great lib for this.=C2=A0 I can&#39;t remember what package= it is in but it has things like isTty() and all of the colors as well ad q= uerying for different color support.=C2=A0 For a name may I recommend std.t= erm.<br> </p> --0015175d03b2ed148404bb14e271--
Mar 12 2012
prev sibling 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

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 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 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
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 "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 "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 next 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 "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 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 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
prev sibling next sibling parent "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
prev sibling 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 next sibling 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 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 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 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
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 next sibling parent 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=




 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 =

 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=

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

 the user.


 Anyhow, here are my objectives:

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

 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=

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

 '%%' 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=

 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=

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

 and refine if there are objections.

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

 (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=

 be easy to find; discovery should be intuitive.


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

 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
prev sibling next sibling parent 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=

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

 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=

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

 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
prev sibling next sibling parent "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
prev sibling next sibling parent 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=

 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
prev sibling next sibling 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=


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



 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=

 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 next sibling parent "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
prev sibling 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
prev sibling parent "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