It's now possible to adjust the tag generation if the Timber is wrapped into another logger framework

[jakubkrolewski]

Let's image that we don't want to use Timber directly in our applications, but we have a custom interface for logging that use a Timber delegate as its implementation. Let's call that interface "Logger". So in the debug log we want to print the line when Logger.d() was called, not Timber.d() (we already know this line, it's always inside our "Logger").
The aim of this change is to make possible to customize which line from the calling stack trace should be printed by the DebugTree.

[jakubkrolewski]

So how about merging that one? :)

[JakeWharton]

API-wise this change is very awkward. I do not like it as is. I'm leaving it open for discussion and to remind me to try to think of something a bit more elegant.

[jakubkrolewski]

The whole case with getting the sixth stack trace element and using it for logging is a little bit strange, but as far as I know this is the best way to print the logging context and I think that my change is a good move to make Timber customizable for the use case mentioned in the description.

[kkocel]

@JakeWharton can You elaborate more on what You mean by 'API-wise'? Did You mean that methods are public and package-scope visible?

[JakeWharton]

Yes. And that it's just a magic number that you have to return.

On Tue Jan 20 2015 at 6:55:12 AM Christopher Kocel notifications@github.com
wrote:

@JakeWharton https://github.com/JakeWharton can You elaborate more on
what You mean by 'API-wise'? Did You mean that methods are public and
package-scope visible?

—
Reply to this email directly or view it on GitHub
#37 (comment).

[jakubkrolewski]

So how about doing it this way?

tag = stackTrace[5 + getOmmitedStactraceLevels()].getClassName();

protected int getOmmitedStactraceLevels() {
    return 0;
}

[SimonVT]

Or pass it a list of packages/classes to skip?

[JakeWharton]

That is a much more appropriate solution. Maybe it's a callback with a
package name that returns a boolean as to whether to continue walking up
the trace.
On Jan 21, 2015 2:09 AM, "Simon Vig Therkildsen" notifications@github.com
wrote:

Or pass it a list of packages/classes to skip?

—
Reply to this email directly or view it on GitHub
#37 (comment).

[SimonVT]

Or pass the Throwable to a callback that returns a String? Then the user can implement it however they like (walk trace a fixed number of steps, base on package, ..).
You can still default to what's in Timber now (which will fit most).

[JakeWharton]

Nice. I like that.

On Wed Jan 21 2015 at 2:30:36 AM Simon Vig Therkildsen <
notifications@github.com> wrote:

Or pass the Throwable to a callback that returns a String? Then the user
can implement it however they like (walk trace a fixed number of steps,
base on package, ..).
You can still default to what's in Timber now (which will fit most).

—
Reply to this email directly or view it on GitHub
#37 (comment).