mainak90 / colorify Goto Github PK

First of all, nice lib!

The idea of:

// Start the init function
redPrint := red.New()
yellowPrint := yellow.New()

yellowPrint.Println("This is yellow regular!!!")

or, representing each color as object is an interesting idea. However, if a cli program wants to have 4 or more colors in its output, like a column-based colorizer which is usually done for coloring logs, this could lead to a lot of go objects that needs to be instantiated. Thus, maybe representing a simple or static function that you call directly, for example:

colorify.Yellow("This line is yellow: %s", yellowWord)
colorify.Red("This line is red: %s", redWord)

without requiring an object to be new() might make the library caller a bit simpler to deal with it. Alternatively, you could have one single initialization of the object, the colorify object as then use for the other colors:

color = colorify.New(....)

color.Yellowf("This line is yellow: %s", yellowWord)
color.Redf("This line is red: %s", redWord)

Isn't too bad to make new() all variable, but; it make simpler to use if such or similar facilities are available. And, we the lib could simply allow both way and the caller decide which one to pick for its program :)

The func (c *Colorify) New() *Colorify, function uses the isatty() to decide when to enable/disable the color based on whether the stdout or /fd/1 points to terminal-like file description. This is very nice way to make the coloring disable automatically when no-terminal is presented. The code will, also; disable coloring when a stdout redirection, such as |; is made on the program. For instance, something like:

log-colorizer file.log | grep -i PCI

will automatically disable the coloring of my program when use colorify library. As developer, I might to carry over the coloring when a non-terminal like file description is presented. For instance, the user might not want to loose the colors if when using a paginator such as less or more.

Therefore, I think it will be nice idea to allow the caller of the library to decide whether:

1. Coloring will be enable/disable automatically based on the isatty() function (which is the default)
2. Enable coloring
3. Disable coloring

which is usually expose in the form an command-line option (i.e: --color=auto|true|false,) for the cli program. Then, allowing the user to disable/enable at will and leaving the default behavior to automatically decide -- which is the current code.

One implementation will be to teach the New() function a new option that will have three-state variable: auto, true or false, given the developer and, potentially; the user to actually decide when color should be present or not.

GH actions pipeline to be added into the project.
Pipeline to run before merge to main branch.