digitalmars.D - How about colors and terminal graphics in std.format?
- Chad J (23/23) Mar 11 2012 I remember doing colored terminal output in Python. It was pretty
- =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= (4/28) Mar 11 2012 --
- Andrei Alexandrescu (8/32) Mar 11 2012 I don't know, seems interesting but I wonder how portable that could be....
- Damian Ziemba (6/56) Mar 11 2012 Some basic stuff like Colors can be portable.
- =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= (6/44) Mar 11 2012 It works for .NET:
- Chad J (46/78) Mar 11 2012 My intent is to make it easy to use. If it's not easy to use, I
- James Miller (24/112) Mar 11 2012 g
- Damian Ziemba (32/82) Mar 11 2012 It could work.
- Damian Ziemba (2/91) Mar 11 2012 Those numbers are for Windows btw :p
- Adam D. Ruppe (18/19) Mar 11 2012 It is also the way the VGA hardware works... and it
- Chad J (5/52) Mar 11 2012 If you can show me you're work and it's licensed in a way that I can use...
- Damian Ziemba (4/72) Mar 11 2012 Sure, give me some time and I will prepare code.
- Damian Ziemba (12/80) Mar 12 2012 Hey Chad.
- Kevin Cox (5/6) Mar 12 2012 std.terminal/std.console or maybe somekind of spot in std.stdio.
- Damian Ziemba (10/20) Mar 12 2012 Urwid?
- Chad J (4/79) Mar 12 2012 Hey, np about the delay. I'm not going to get to working on this stuff
- Adam D. Ruppe (13/13) Mar 11 2012 One concern I have with this is format() creates a
- Chad J (15/28) Mar 11 2012 I was kind of intending to /not/ do that, for exactly the reasons you
- Adam D. Ruppe (10/15) Mar 11 2012 If it is done on the output part, that's ok. Really,
- Mantis (24/48) Mar 11 2012 This is not exactly what you mean, but related. There are some graphics
- H. S. Teoh (9/13) Mar 11 2012 [...]
- Jacob Carlborg (5/19) Mar 12 2012 I think it would nice to have, but not in std.format. std.terminal or
- H. S. Teoh (19/41) Mar 12 2012 [...]
- Chad J (30/69) Mar 12 2012 I never felt it would go into std.terminal because I have a fairly
- James Miller (28/109) Mar 12 2012 be all
- Chad J (13/27) Mar 12 2012 I do want to be able to format things besides color with the color
- Chad J (17/46) Mar 12 2012 Actually, wait a sec.
- James Miller (25/54) Mar 12 2012 rmat.
- Chad J (35/90) Mar 12 2012 Why? This would be an addition of features for writef(ln), not an
- James Miller (16/18) Mar 12 2012 Actually, I meant more to make sure that any output is reset to the
- Chad J (9/26) Mar 12 2012 Oh, I see what you mean.
- James Miller (8/44) Mar 12 2012 want
- Sean Cavanaugh (6/11) Mar 12 2012 There are something like 4 million UTF characters designated for
- Christian Manning (6/34) Mar 12 2012 It would be great if an std.terminal contained general stuff for
- Chad J (7/15) Mar 12 2012 Although this would be cool, it is out of the scope of what I am willing...
- Christian Manning (3/19) Mar 12 2012 That's fair enough, I was mostly making a point that both things
- H. S. Teoh (6/24) Mar 12 2012 We could start off with said module just doing colors for now, and then
- James Miller (4/6) Mar 12 2012 We could end up at a D-flavoured ncurses library!
- H. S. Teoh (11/16) Mar 12 2012 [...]
- Chad J (3/16) Mar 12 2012 Yes.
- Jacob Carlborg (4/8) Mar 13 2012 I actually have a library for this written in C++, somewhere.
- Christian Manning (4/13) Mar 13 2012 Any chance of a release? :)
- Jacob Carlborg (5/17) Mar 13 2012 I have been thinking about porting it to D from time to time. I can see
- Christian Manning (2/24) Mar 13 2012 Looking forward to it!
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
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
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
On Monday, 12 March 2012 at 02:52:15 UTC, Andrei Alexandrescu wrote:On 3/11/12 9:16 PM, Chad J wrote:Some basic stuff like Colors can be portable. I can share my work if somebody is interested. Best regards, Damian ZiembaI 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
On 12-03-2012 03:52, Andrei Alexandrescu wrote:On 3/11/12 9:16 PM, Chad J wrote:It works for .NET: http://msdn.microsoft.com/en-us/library/system.consolecolor.aspx This is implemented across all platforms in Mono.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.-- - AlexOh, 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
On 03/11/2012 10:52 PM, Andrei Alexandrescu wrote:On 3/11/12 9:16 PM, Chad J wrote: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. }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.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.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
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=gand allows for some slick CLI design. I think D can do better by puttin=ldn'tMy intent is to make it easy to use. =C2=A0If it's not easy to use, I wou=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.use it. =C2=A0If someone wants low-level, they can help themselves to cur=ses. =C2=A0Itshould be possible to do this reasonably portably. =C2=A0I know Python wa=s ableto 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=olsequences 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. }=A0Such aAlright, 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=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. Andreithing would be really useful for me if I want to feel like working on thi=sstuff 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
On Monday, 12 March 2012 at 02:52:15 UTC, Andrei Alexandrescu wrote:On 3/11/12 9:16 PM, Chad J wrote: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 PosixI 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
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:Those numbers are for Windows btw :pOn 3/11/12 9:16 PM, Chad J wrote: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 PosixI 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
On Monday, 12 March 2012 at 03:30:09 UTC, Damian Ziemba wrote:Those numbers are for Windows btw :pIt 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
On 03/11/2012 11:27 PM, Damian Ziemba wrote:On Monday, 12 March 2012 at 02:52:15 UTC, Andrei Alexandrescu wrote:Good catch.On 3/11/12 9:16 PM, Chad J wrote: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.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....Andreipublic 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 PosixIf 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
On Monday, 12 March 2012 at 03:32:26 UTC, Chad J wrote:On 03/11/2012 11:27 PM, Damian Ziemba wrote:Sure, give me some time and I will prepare code. Framework is BSD licensed but I can relicense it to whatever you want.On Monday, 12 March 2012 at 02:52:15 UTC, Andrei Alexandrescu wrote:Good catch.On 3/11/12 9:16 PM, Chad J wrote: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.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....Andreipublic 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 PosixIf 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
On Monday, 12 March 2012 at 03:32:26 UTC, Chad J wrote:On 03/11/2012 11:27 PM, Damian Ziemba wrote: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 ZiembaOn Monday, 12 March 2012 at 02:52:15 UTC, Andrei Alexandrescu wrote:Good catch.On 3/11/12 9:16 PM, Chad J wrote: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.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....Andreipublic 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 PosixIf 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 12 2012
On Mar 12, 2012 7:55 PM, "Damian Ziemba" <spam dzfl.pl> wroteAnd yea, I think like others that it should have its own module likestd.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
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> wroteUrwid? 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.And yea, I think like others that it should have its own module likestd.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
On 03/12/2012 07:51 PM, Damian Ziemba wrote:On Monday, 12 March 2012 at 03:32:26 UTC, Chad J wrote:Hey, np about the delay. I'm not going to get to working on this stuff that soon anyways. Thanks for the code!On 03/11/2012 11:27 PM, Damian Ziemba wrote: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 ZiembaOn Monday, 12 March 2012 at 02:52:15 UTC, Andrei Alexandrescu wrote:Good catch.On 3/11/12 9:16 PM, Chad J wrote: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.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....Andreipublic 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 PosixIf 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 12 2012
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
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
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
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
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
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
On Mon, Mar 12, 2012 at 10:51:08AM +0100, Jacob Carlborg wrote:On 2012-03-12 03:16, Chad J wrote:[...] +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.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.
Mar 12 2012
On 03/12/2012 11:02 AM, H. S. Teoh wrote:On Mon, Mar 12, 2012 at 10:51:08AM +0100, Jacob Carlborg wrote: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.On 2012-03-12 03:16, Chad J wrote:[...] +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. TI 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.
Mar 12 2012
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:fOn 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=be allI 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 =[...] +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. Tthese 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.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=omthe user. Anyhow, here are my objectives: What I really want is to have an /easy/ way to do color formatting. =C2==A0I wantto 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=etanother 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=idstuff 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=hisisn't what others feel. =C2=A0Nonetheless, I'm inclined to start from int=uitionand 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=dbe easy to find; discovery should be intuitive. If someone has a good vision that accomplishes these things, then please =doshare.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
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 MillerI 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
On 03/12/2012 11:58 PM, Chad J wrote:On 03/12/2012 10:37 PM, James Miller wrote: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.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 MillerI 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
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:rs firstI 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 MillerI 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=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 Ithink that stack traces with color highlights would be awesome. =C2=A0It'=s prettyin-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
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:Why? This would be an addition of features for writef(ln), not an alteration. Existing writef(ln) usage would remain exactly the same.On 03/12/2012 10:37 PM, James Miller wrote: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.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 MillerI 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.%)");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 MillerAh, 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
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 towrite 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
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: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.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
Mar 12 2012
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:wrote:On 13 March 2012 18:24, Chad J<chadjoan __spam.is.bad__gmail.com> =C2=A0=wantI'm not sure I agree with resetting to a default color. =C2=A0What if I=selfOh, 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=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 Millerdoes 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
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
On Monday, 12 March 2012 at 09:51:08 UTC, Jacob Carlborg wrote:On 2012-03-12 03:16, Chad J 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 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.
Mar 12 2012
On 03/12/2012 09:36 PM, Christian Manning wrote:On Monday, 12 March 2012 at 09:51:08 UTC, Jacob Carlborg wrote: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.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
On Tuesday, 13 March 2012 at 01:53:11 UTC, Chad J wrote:On 03/12/2012 09:36 PM, Christian Manning wrote:That's fair enough, I was mostly making a point that both things are closely related and would make sense in a common module.On Monday, 12 March 2012 at 09:51:08 UTC, Jacob Carlborg wrote:Although this would be cool, it is out of the scope of what I am willing to spend time on.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
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: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 DamageOn 03/12/2012 09:36 PM, Christian Manning wrote:That's fair enough, I was mostly making a point that both things are closely related and would make sense in a common module.On Monday, 12 March 2012 at 09:51:08 UTC, Jacob Carlborg wrote:Although this would be cool, it is out of the scope of what I am willing to spend time on.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
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
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:[...] 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.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!
Mar 12 2012
On 03/13/2012 01:34 AM, H. S. Teoh wrote:On Tue, Mar 13, 2012 at 03:17:42PM +1300, James Miller wrote:Yes. Maybe someday...On 13 March 2012 15:17, H. S. Teoh<hsteoh quickfur.ath.cx> wrote:[...] 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. TWe 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!
Mar 12 2012
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
On Tuesday, 13 March 2012 at 07:45:19 UTC, Jacob Carlborg wrote:On 2012-03-13 02:36, Christian Manning wrote: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.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.
Mar 13 2012
On 2012-03-13 13:31, Christian Manning wrote:On Tuesday, 13 March 2012 at 07:45:19 UTC, Jacob Carlborg wrote:I have been thinking about porting it to D from time to time. I can see what I can do :) -- /Jacob CarlborgOn 2012-03-13 02:36, Christian Manning wrote: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.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.
Mar 13 2012
On Tuesday, 13 March 2012 at 16:05:31 UTC, Jacob Carlborg wrote:On 2012-03-13 13:31, Christian Manning wrote:Looking forward to it!On Tuesday, 13 March 2012 at 07:45:19 UTC, Jacob Carlborg wrote:I have been thinking about porting it to D from time to time. I can see what I can do :)On 2012-03-13 02:36, Christian Manning wrote: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.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.
Mar 13 2012