Re: How about colors and terminal graphics in std.format?
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. Teohhst...@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...
Re: How about colors and terminal graphics in std.format?
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 Jchadjoan@__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.
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
Re: How about colors and terminal graphics in std.format?
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
Re: How about colors and terminal graphics in std.format?
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.
Re: How about colors and terminal graphics in std.format?
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
Re: How about colors and terminal graphics in std.format?
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!
Re: How about colors and terminal graphics in std.format?
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
Re: How about colors and terminal graphics in std.format?
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.
Re: How about colors and terminal graphics in std.format?
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 = 0x,
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
Re: How about colors and terminal graphics in std.format?
On Mar 12, 2012 7:55 PM, Damian Ziemba s...@dzfl.pl wrote And yea, I think like others that it should have its own module like std.terminal/std.console or maybe somekind of spot in std.stdio. Python has a great lib for this. I can't remember what package it is in but it has things like isTty() and all of the colors as well ad querying for different color support. For a name may I recommend std.term.
Re: How about colors and terminal graphics in std.format?
On Tuesday, 13 March 2012 at 00:24:58 UTC, Kevin Cox wrote: On Mar 12, 2012 7:55 PM, Damian Ziemba s...@dzfl.pl wrote And yea, I think like others that it should have its own module like std.terminal/std.console or maybe somekind of spot in std.stdio. Python has a great lib for this. I can't remember what package it is in but it has things like isTty() and all of the colors as well ad querying for different color support. For a name may I recommend std.term. Urwid? Well there are Ncurses bindings lying around, but I guess the point is to get something rather simple. Ofcourse porting for example Urwid from Python to D would be possible but I am not sure if there is a point in doing so. In my framework I've added only stuff that I missed from MS Class Library, and actually were useful, like Console.ReadKey or Console.ForegroundColor. I think that Chad idea was to provide something simple like that.
Re: How about colors and terminal graphics in std.format?
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.
Re: How about colors and terminal graphics in std.format?
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.
Re: How about colors and terminal graphics in std.format?
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
Re: How about colors and terminal graphics in std.format?
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.
Re: How about colors and terminal graphics in std.format?
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. 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. 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
Re: How about colors and terminal graphics in std.format?
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 = 0x,
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!
Re: How about colors and terminal graphics in std.format?
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.%));
Re: How about colors and terminal graphics in std.format?
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.
Re: How about colors and terminal graphics in std.format?
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. 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
Re: How about colors and terminal graphics in std.format?
On 03/13/2012 12:15 AM, James Miller wrote: On 13 March 2012 16:58, Chad Jchadjoan@__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. .. ... FFF 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.
Re: How about colors and terminal graphics in std.format?
On Tue, Mar 13, 2012 at 03:17:42PM +1300, James Miller wrote: On 13 March 2012 15:17, H. S. Teoh hst...@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.
Re: How about colors and terminal graphics in std.format?
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.
Re: How about colors and terminal graphics in std.format?
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
Re: How about colors and terminal graphics in std.format?
On 03/13/2012 01:41 AM, James Miller wrote:
On 13 March 2012 18:24, Chad Jchadjoan@__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.
Re: How about colors and terminal graphics in std.format?
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
Re: How about colors and terminal graphics in std.format?
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
Re: How about colors and terminal graphics in std.format?
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
Re: How about colors and terminal graphics in std.format?
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
Re: How about colors and terminal graphics in std.format?
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;
}
//
Re: How about colors and terminal graphics in std.format?
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.
Re: How about colors and terminal graphics in std.format?
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.
Re: How about colors and terminal graphics in std.format?
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.
Re: How about colors and terminal graphics in std.format?
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 = 0x,
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
Re: How about colors and terminal graphics in std.format?
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 = 0x,
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
Re: How about colors and terminal graphics in std.format?
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 = 0x,
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.
Re: How about colors and terminal graphics in std.format?
On 12 March 2012 16:15, Chad J chadjoan@__spam.is.bad__gmail.com wrote:
On 03/11/2012 10:52 PM, Andrei Alexandrescu wrote:
On 3/11/12 9:16 PM, Chad J wrote:
I remember doing colored terminal output in Python. It was pretty nifty,
and allows for some slick CLI design. I think D can do better by putting
it in the standard library.
I was thinking something along the lines of this:
http://www.chadjoan.com/d/dmd.2.058/html/d/phobos/std_format.html
...
If there's interest, I might take a stab at it.
So, would this sort of thing make it in?
I don't know, seems interesting but I wonder how portable that could be.
Probably I'd define a more general means a la %q to mean send a control
sequence and then would define control sequences as functions or
constants.
My intent is to make it easy to use. If it's not easy to use, I wouldn't
use it. If someone wants low-level, they can help themselves to curses. It
should be possible to do this reasonably portably. I know Python was able
to do this well on both my Linux install and my Windows install.
If other OSes have known issues, it can be solved by using either better
feature detection or simply version()'ing out the code that inserts control
sequences on those OSes.
My plan would be something like this:
version(Windows)
{
// There is only one possible way to do this:
// Call WinAPI functions.
}
else version(Posix)
{
Look for the terminfo database.
Check $TERMINFO,
then ~/.terminfo,
then /usr/share/terminfo,
then /usr/lib/terminfo,
then /etc/terminfo,
then give up if not found.
if ( terminfo found )
{
query terminfo for terminal capabilities and sequences
emit sequences as appropriate
}
else
{
Don't output control sequences.
}
// Using term.h might be easier,
// but I don't know how portable it is. :/
}
else
{
// Don't output control sequences.
}
Oh, on an unrelated note, Phobos' documentation make target is quite
broken:
blahblah/dmd.git/src/phobos $ make -fposix.mak html
make: *** No rule to make target `../web/phobos-prerelease/index.html',
needed by `html'. Stop.
I examined the makefile and concocted this line of bash that constructs
my desired html file:
dmd -m32 -d -c -o- -version=StdDdoc -I../druntime/import std/format.d
std.ddoc -Dfstd_format.html
and copied std.ddoc from a release version of dmd (it's in src/phobos).
Since recently the Phobos doc build is meant to be driven from the site
build. I'll fix the standalone thing because it's useful too, just I
don't know when.
Andrei
Alright, thanks!
Btw, did we ever get a git repo that includes the release files for D and
tracks dmd/druntime/phobos as sub-repositories at the correct paths? Such a
thing would be really useful for me if I want to feel like working on this
stuff very much. I don't think I have the ability to update DMD
documentation from git right now.
Another thing is that on UNIX there technically isn't a standard way
to put out colors. Ideally you'd want to interrogate termcap in those
instances. This also means that you output the correct sequences when
terminals don't support color, i.e., nothing. Terminals are strange,
complicated beasts.
--
James Miller
Re: How about colors and terminal graphics in std.format?
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.
Re: How about colors and terminal graphics in std.format?
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 = 0x,
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.
Re: How about colors and terminal graphics in std.format?
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.
Re: How about colors and terminal graphics in std.format?
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 -- Живёшь только однажды.
