Alan Shreve

@tve Thanks for pointing it out! That's not actually poor practice, it's just poorly communicated how those two things should tie together. Your library should have context loggers embedded in...

Yeah, i think that would make a great addition to the readme. Happy to take a patch with that!

You could write a simple handler to add this for you, but it's going to be a separate key instead of 't': ``` func epochHandler(nextHandler log.Handler) log.Handler { return log.FuncHandler(func(r...

Yep, I agree. It's a temporary work around. We'd like to make formatters more flexible to tweaking, like Chris said in a future release.

The native Go toolchain supports cross-compilation sufficiently well for all of the usecases I need now.

what is it exactly that you're trying to do?

yes, that's correct, for the most part it's not relevant anymore. there are still a few cases where that *might* matter to you, but they're even more rare than before...

It's pretty easy to implement this with your own handler. Do we think this is a common enough case that it needs to be included as a standard component?

@GeertJohan I'm not sure I understand why this is a problem. The redactor interface returns the new readacted object to log instead, so dealing with pointers and copying or whatever...

I wonder if the best documentation for this would be to start a "examples" or "patterns" section of the README (or separate file) that shows how you might want to...