Allow override for tag depth

[drewhamilton]

Pull DebugTree.CALL_STACK_INDEX into a protected getLoggingDepth() method. This is useful for apps that wrap Timber and don't want every tag to be "TimberWrapper" or whatever. Does not affect default behavior for users who don't want/need this.

[drewhamilton]

Sort of addresses #180, but only on a per-tree basis rather than a per-log basis.

[drewhamilton]

Any interest in this? It goes a long way in allowing use of Timber with Java-only modules without requiring much change or maintenance from Timber IMO.

[tonisives]

This would be helpful for us. Currently resolved to calling Timber.tag(getTagFromStackTrace()) before logging calls.

[dvdciri]

Is this going to be merged anytime soon? Would be very helpful when wrapping timber around your own logger, and be able still get the class name calling your custom wrapper.

[whoyawn]

Do any of the debug tree's methods help in getting the tag from the stack trace or do we have to subclass DebugTree/get the stack trace ourselves without the api?

[drewhamilton]

@whoyawn createStackElementTag is protected, so you have to subclass DebugTree to get access to it. But the call stack index it looks for is defined in package-private, final getTag, so to change how createStackElementTag is called you really have to create a completely new Tree class and copy/paste the portions of DebugTree logic you want.

This PR allows you to change that call stack index by overriding DebugTree, so you don't have to copy/paste. Though it really should take that index via constructor or setter, so you don't even have to override. I'll update it to do that if Jake shows any interest in merging this (which he probably won't because the master branch already has a completely different default tree for Timber 5).

[drewhamilton]

Closing this because it's very out of date (e.g. the main branch is now in Kotlin rather than Java).

[TurKurT656]

Any workaround here? I really need this feature

[drewhamilton]

You can create your own subclass of Tree in your app that behaves however you like.

[TurKurT656]

@drewhamilton But the problem is that tag is an internal field and so we can't override that.

[drewhamilton]

Ah you're right, I forgot about that. #362 is the Kotlin version of this PR; it's still open.