On Mar 12, 2012 7:55 PM, "Damian Ziemba" <spam@dzfl.pl> wrote
> And yea, I think like others that it should have its own module like
std.terminal/std.console or maybe somekind of spot in std.stdio.

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

On Tuesday, 13 March 2012 at 00:24:58 UTC, Kevin Cox wrote:
> On Mar 12, 2012 7:55 PM, "Damian Ziemba" <spam@dzfl.pl> wrote
>> And yea, I think like others that it should have its own module like
> std.terminal/std.console or maybe somekind of spot in std.stdio.
>
> Python has a great lib for this.  I can't remember what package it is in
> but it has things like isTty() and all of the colors as well ad querying
> for different color support.  For a name may I recommend std.term.

Urwid?

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

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

I think that Chad idea was to provide something simple like that.

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.

On 03/12/2012 09:36 PM, Christian Manning wrote:
> On Monday, 12 March 2012 at 09:51:08 UTC, Jacob Carlborg wrote:
>>
>> I think it would nice to have, but not in std.format. std.terminal or
>> similar would be better.
>
> It would be great if an std.terminal contained general stuff for
> manipulating/querying a terminal portably, as well as colour output, eg.
> get terminal size, move cursor around, erase line... just things to help
> with building UIs, progress bars, etc. that are easy to use.

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

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

I might do it someday if I feel like writing a game using terminal graphics, but even then there is no guarantee it would be phobos worthy.

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.

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

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

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.

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

On 03/12/2012 07:51 PM, Damian Ziemba wrote:
> On Monday, 12 March 2012 at 03:32:26 UTC, Chad J wrote:
>> On 03/11/2012 11:27 PM, Damian Ziemba wrote:
>>> On Monday, 12 March 2012 at 02:52:15 UTC, Andrei Alexandrescu wrote:
>>>> On 3/11/12 9:16 PM, Chad J wrote:
>>>>> I remember doing colored terminal output in Python. It was pretty
>>>>> nifty,
>>>>> and allows for some slick CLI design. I think D can do better by
>>>>> putting
>>>>> it in the standard library.
>>>>>
>>>>> ...
>>>>>
>>>>> So, would this sort of thing make it in?
>>>>
>>>> I don't know, seems interesting but I wonder how portable that could
>>>> be. Probably I'd define a more general means a la %q to mean "send a
>>>> control sequence" and then would define control sequences as functions
>>>> or constants.
>>>>
>>>>> ...
>>>>
>>>> Andrei
>>>
>>> It could work.
>>> In my small framework I use version blocks and I use ansi escape
>>> sequences for posix and SetConsoleTextAttribute for windoze.
>>>
>>> Ofcourse there would be a need to create unified enumeration with colors
>>> as they differ on those platforms too.
>>>
>>
>> Good catch.
>>
>>>
>>> public enum Font
>>> {
>>> Normal = 0,
>>> Underline = 0x8000,
>>> Reverse = 0x4000,
>>> }
>>>
>>> public enum Color
>>> {
>>> Default = 0x0000,
>>> Blue = 0x0001,
>>> Green = 0x0002,
>>> Aqua = 0x0003,
>>> Red = 0x0004,
>>> Purple= 0x0005,
>>> Yellow= 0x0006,
>>> Gray = 0x0008,
>>> LightBlue = 0x0009,
>>> LightGreen = 0x000A,
>>> LightAqua = 0x000B,
>>> LightRed = 0x000C,
>>> LightPurple= 0x000D,
>>> }
>>>
>>> Those are colors and font-attributes that I found to match both Windows
>>> and Posix
>>>
>>
>> If you can show me you're work and it's licensed in a way that I can
>> use it in Phobos, then I'll happily try to make use of it. It'd be
>> much appreciated.
>
> Hey Chad.
>
> Sorry for delay, been a bit busy.
> Here it is: https://gist.github.com/2025473
> I hope it can help you somehow.
> (There is place for improvments I know but I used it mostly for
> debbuging stuff ;))
>
> And yea, I think like others that it should have its own module like
> std.terminal/std.console or maybe somekind of spot in std.stdio.
>
> Best Regards,
> Damian Ziemba

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

Thanks for the code!