Minorly tweaking log output

[nic-hartley]

Hello!

I'm trying to adopt tracing-forest for a project. One quirk of this project is that I, personally, dislike both the drawing characters (not sure what they're called; these: ┝━) as well as emoji for marking log levels (e.g. 📍 [trace]). (This paragraph used to be a very long rant about them. Suffice to say: Not a fan. I'd like them to not be in my log output.)

Unfortunately I can't find a way to get rid of them? Granted, I'm quite new to tracing-anything, so it's possible I'm just looking in the wrong place, but the concept of an "icon" seems to be defined by tracing-forest, and there doesn't seem to be a way to dissociate the icons from the log messages. I can't even find a way to format the messages, either, leading to other annoying effects like having the log level twice (once from the default output, I think, and once within the tree).

So I think what I'm looking for, and failing to find, is a place to specify format strings, which will presumably allow me to specify one without the icon. Could someone point me to that?

The closest I've been able to find is trait Formatter, which has one implementation (as far as I can tell, the one with the behavior I dislike) and... that's it! I suppose I could write my own, but rewriting the ~250 lines of pretty.rs just to delete one character is not my first choice.

[nic-hartley]

I understand the crate is still quite early on, and I'm happy to work on a PR to add this functionality -- but again, I'm very new to the tracing ecosystem, so I have no idea how much help I'd actually be.

[QnnOkabayashi]

Hi Nic, I've been on vacation for the past 2.5 weeks so apologies for the delayed response.

If I understand correctly, you want to be able to just have the log level once on the left and then your (appropriately space indented) text on the right. Here's an example of what I assume you mean:

INFO     try_from_entry_ro [ 324µs | 8.47% / 100.00% ]
INFO        server::internal_search [ 296µs | 19.02% / 91.53% ]
INFO           Some filter info...
INFO           server::search [ 226µs | 10.11% / 70.01% ]
INFO              be::search [ 181µs | 6.94% / 55.85% ]
INFO                 be::search -> filter2idl [ 158µs | 19.65% / 48.91% ]
INFO                    be::idl_arc_sqlite::get_idl [ 20.4µs | 6.30% ]
INFO                       Some filter info...
INFO                    be::idl_arc_sqlite::get_idl [ 74.3µs | 22.96% ]
ERROR                      On no, an admin error occurred :(
DEBUG                      An untagged debug log
INFO                       there's been a big mistake | alive: false | status: "very sad"
INFO              be::idl_arc_sqlite::get_identry [ 13.1µs | 4.04% ]
ERROR                A security critical log
INFO                 A security access log
INFO           server::search<filter_resolve> [ 8.08µs | 2.50% ]
WARN              Some filter warning
TRACE       Finished!

Right now, there's no easy way to do this, aside from lots of copy pasting from pretty.rs. However, if you want to help contribute to make this process easier for others, that's welcome too, and I'm happy to discuss paths forward for that.

My initial thought for that would be to make the Pretty type be generic over a bunch of custom types that implemented helper traits. For example, there could be FormatIndentation, FormatTag, and FormatFields traits that Pretty uses for their respective purposes. That way, you could implement your own types for these without rewriting all logic of pretty.rs. If this is something that interests you, let me know and we can discuss further :)

[nic-hartley]

No worries, everyone deserves vacations, including open-source maintainers.

I'd certainly be down to give it a shot! I'd also quite like an implementation based on format strings, for convenience -- I know it's less efficient (unless we do a proc macro, I guess?) but it's also really easy to use.

I might just throw together a quick PR and then we can iterate from there, if that works for you?