Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Color customization #48

Closed
wants to merge 1 commit into from
Closed

Color customization #48

wants to merge 1 commit into from

Conversation

topi314
Copy link

@topi314 topi314 commented Nov 4, 2023

This pr adds the ability to customize the color of nearly all elements of a log line.
I don't expect this pr to necessarily get merged, but I figured it would be worth trying since that's what I, as a user want. In case this does not get merged I can just keep maintaining my fork no problem.

I made sure the current log colors are the default. If wanted I could add a new predefined default theme, but I don't think this is necessary. I'm open to address any feedback

The following different kind of thing can be colorized in a log line (it is sorted in order of their usual appearance):

const (
	KindTime Kind = iota
	KindSourceFile
	KindSourceSeparator
	KindSourceLine
	KindMessage
	KindGroup
	KindKey
	KindSeparator
	KindValue
	KindErrorKey
	KindErrorSeparator
	KindErrorValue
)

@topi314
Copy link
Author

topi314 commented Nov 4, 2023

I also changed tint.Err to not return a tintError since that's a weird behavior imo.
If let's say a library logs an error, the error is not being logged red unless they also depend on the tint module which is really annoying

@lmittmann
Copy link
Owner

I also changed tint.Err to not return a tintError since that's a weird behavior imo.

If let's say a library logs an error, the error is not being logged red unless they also depend on the tint module which is really annoying

That's a feature. It allows you to use different handlers in different environments, e.g tint in dev and slog's JSON handler in prod. You don't want your json log to contain ansi codes.

@topi314
Copy link
Author

topi314 commented Nov 5, 2023

I'm not sure why this is needed then, I already use the json handler for production and I don't have any ansi codes in my production logs

@lmittmann
Copy link
Owner

It is needed because tint should not print every error in red color, but only those wrapped in tint.Err(...). And errors wrapped in tint.Err(...) should just be "normal" errors to all the other handlers.

@lmittmann
Copy link
Owner

Thank's for the effort, but I will not merge the changes. tint provides an opinionated output format, that can be customized to some extend via Options.ReplaceAttr (e.g. change level colors), or can be forked to tailor the output format to your liking. Also this PR degrades performance quite a lot.

@lmittmann lmittmann closed this Nov 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants