[ANN] color: ANSI Color package for Go

[Fatih Arslan]

Hi everyone,

I needed a color package with a simple and useful API for my upcoming projects. Most of the packages in godoc index has a different and difficult to use API. I also tried to add some tests (which I'm not sure if they are %100 correct). This package has several ways of colorizing texts to make it as flexible as possible. Check it out: 

source: https://github.com/fatih/color

godoc: http://godoc.org/github.com/fatih/color

Any suggestions and improvements are welcome!

Regards

Fatih Arslan

[egon]

Relevant:

https://github.com/kortschak/ct

https://github.com/agtorre/gocolorize

https://github.com/mgutz/ansi

Why not improve on those instead of reinventing things?

Will that package really solve your problem cleanly?

e.g it doesn't nicely compose

color.Set(color.FgYellow)

fmt.Println("Yellow")

// somewhere inside a function

color.Set(color.FgBlue)

fmt.Println("Blue")

color.Unset()

// ....

fmt.Println("Default")

color.Unset()

fmt.Println("Default")

I would guess usually you need to color parts of a single line instead per line.

e.g. how the API could look....

fmt.Printf("%(red)WARNING:%(~) %v\n", text)

vs.

warning := color.Mode(color.FgRed | color.BgBlack)

fmt.Printf("%v: %v\n", warning("warning"), text)

vs.

fmt.Printf("%v: %v\n", color.Red("warning"), text)

vs.

prev := color.GetFg()

color.Set(color.FgRed)

fmt.Printf("WARNING:")

color.Set(prev)

fmt.Printf(" %v", text)

vs.

color.Set(color.FgRed)

fmt.Printf("WARNING:")

color.Undo()

fmt.Printf(" %v", text)

I would probably prefer v2 since it would decouple the intent of the coloring from the actual usage code. Imagine what would you have to change when the terminal doesn't support coloring and you need to still make that text stand out... e.g. you could replace the "warning" function with "captialize" or prepend some text "## WARNING:" instead of coloring.

TL;DR.. the package seems to focus on per line coloring, but I do not think that's the main use-case.

+ egon

[mattn]

Why not improve on those instead of reinventing things?

Will that package really solve your problem cleanly?

I love https://github.com/daviddengcn/go-colortext

go-colortext support windows.

- mattn

[Fatih Arslan]

Hi egon,

Thanks for the feedback! For the question why not supporting existing
ones. I think that's tricky question, because programmers love to
improve and fix their own problems. It's not a biggie, if people like
this package they will pick it up, otherwise nothing is lost :)

You are right that some important features were missing. I've just add
some SprintXxx and PrintXxx methods which returns functions to be
used. That means it's not anymore only focusing to per line coloring.
See:

https://github.com/fatih/color#custom-print-functions
https://github.com/fatih/color#insert-into-noncolor-strings

This is possible now:

yellow := New(FgYellow).SprintFunc()
red := New(FgRed).SprintFunc()
fmt.Printf("this is a %s and this is %s.\n", yellow("warning"), red("error"))

The method name might be a little long (and ugly) however for now I'm
favor of explicit API calls.
The package is still under ongoing development. I'm planning to
improve the API, another reason why I posted this was too see what's
good and wrong, and improve them. Thanks again for your valuable
feedback.

Regards

> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.



--
Fatih Arslan

[Matthew Holt]

My favorite quote of the week: "Telling a programmer there's already a library to do _____ is like telling a songwriter there's already a song about love."

[egon]

On Tuesday, February 18, 2014 9:12:38 PM UTC+2, Matthew Holt wrote:

My favorite quote of the week: "Telling a programmer there's already a library to do _____ is like telling a songwriter there's already a song about love."

There are usually reasons why the person has decided not to use an existing libraries. That decision can directly show what niche the library is trying to cater to.

Also... having fun and trying new things are valid reasons for making a new library, it's one of the best reasons learning something... also, I do that all the time... but too often it seems that people tend to confuse that with "proper software development". In other words, if you make a new library, are you ready to support the package long term... like 10 years or more? Who will maintain it if you don't have time to maintain it? If as a collective we instead opt to improve existing libraries then we eventually may have really good battle-tested libraries and well thought out APIs.

I know this is a small package... but, I try to ask these kinds for most of the new packages.