Ability to override default colors

[mahendrakariya]

I would like to have the ability to override default colors for various log levels provided.

[giftig]

+1

[op]

I'm open to suggestions. It would be neat to use some library which abstracted these colors to make them work on both Unix and Windows et al.

[mahendrakariya]

This library supports colorized output on Unix and Windows.

[mahendrakariya]

It would also be great if we could specify the color for each call (apart from changing the default colors at log levels).

Here's one use case where I think this feature will really help.
Suppose I am executing a test case. When the execution starts, I would want to print an INFO message (in default color), saying Executing foobar test case. At the end of the execution, if the test passes, I'd want to print another INFO message [PASS] in green color. In case it fails, I'd want to print an INFO message in red color [FAIL] and I can log the stack trace at ERROR level.

[op]

@mahendrakariya That you can do today already using eg. the library you linked to together with this library.

[giftig]

I've made a patch which can override default levels, though it looks like it'll be extra work to add the same feature for formatting "verbs"; I had a stab at the latter but it looks like doFmtVerbLevelColor is called within a StringFormatter, which doesn't have access to the LogBackend, where I put my custom colour scheme option.

See the PR above.

[giftig]

Here's the initial attempt I made at applying it to {color} in formatters, but I ran into the snag I mentioned above so the draft doesn't compile as I haven't got access to my colour scheme in the StringFormatter currently, as I detailed above.

I'd welcome @op 's comments on the signature change on doFmtVerbLevelColor though, and any suggestions as to the most sensible way to pass the desired colour in.

giftig@9a5bb06

[op]

Sorry, I don't have time to look at this right now.

Maybe you could call a function when creating the formatter, eg getColorFunc(string) (func(io.Writer), error). The error is used when creating the formatter in case the color is unknown or unsupported (Windows?). This function could know that it should paint eg. red. Then when creating the log line, use the function as is. Quick sketch (this doesn't work at all);

In new;

if strings.HasPrefix(name, "color") {
  if f, err := getColorFunc(name); err != nil {
    return err
  } else {
    // save func
  }
}

When creating the output format;

for i, part := range parts {
  // ...
  if part.verb == color {
    f.colorFuncs[i](output)
  }
  // ...
}

[giftig]

I'm not sure I understand your suggestion; it sounds like you're suggesting having the formatter string hard code colours in? That seems strange as it wouldn't respect the log level, which is the only thing which woud usually decide the colour used, I would think. My original approach was just going to be to use the custom colours defined for specific log levels, so that instead of being able to only override the colour for the whole line, you could still use the formatter to determine where that colour is applied (eg. in my applications I have it only colourising the WAR/ERR/INF part).

Personally I don't think I'm likely to use more than the feature I've added in that pull request, and I think that's also all this issue expressed a desire for, so I'll leave the verb formatting alone.

It's worth noting, though, that with both the log message colouring on, and {color} used in the formatter, the default log colour will only apply up to the first {color} and then be reset to white, and this is true in the existing code, before my PR.

[op]

Sorry @giftig, sounds like I missunderstood. I thought you wanted to support color:red. Mixed this up with another issue. I'll re-read this later when I have some more time. :)

[mahendrakariya]

Sorry for the delayed update. But after a long discussion, we finally came to a conclusion that for our use case, what we need is "console reporting". Logging is a different functionality and it should not be confused with reporting. So, we will continue using this library for logging, but not for reporting on console. Which means we no longer need the functionality we requested in this issue. But I will keep it open as other users may benefit if this is implemented.

[mageddo]

👍 for set up custom colors to the levels