Add env-filter-explorer example

[joshka]

Motivation

On discord, Conrad suggested a website to experiment with env-filter syntax. I think a TUI in tree makes a pretty decent replacement, especially as the output can exactly match the output that a real user might see if they're configuring tracing_subscriber with the default values.

Solution

This example demonstrates how to use the tracing-subscriber crate's
EnvFilter type to filter log messages based on their metadata. The
example provides a text area where users can input an environment filter
string, and displays the log messages that would be captured by that
filter.

There are preset filters that can be selected that show off the syntax.

[kaffarell]

Wow, this is very nice! Did not yet look at the code in-depth but noticed one issue: When the envfilter is empty, no event is displayed (this is not correct, every event should be shown). Same on bogus input, e.g., when writing "abc" every event should be visible.

[joshka]

This is the result of calling EnvFilterBuilder::parse(). There's nothing more to it than that.

[hds]

EDIT: I think I'm wrong about the implementation of this (but right about the docs), that should probably be fixed.

@kaffarell It depends on the default directive, if none is given then ERROR level is set (see https://docs.rs/tracing-subscriber/latest/tracing_subscriber/filter/struct.EnvFilter.html#method.new).

(This is different from if the env-filter feature isn't enabled at all and fmt::init() is called, in which case all traces are shown)

[hds]

This looks awesome! If we could avoid reformatting unrelated lines in Cargo.toml that would be good though.

[hds]

It would be good if we could avoid reformatting. I think this isn't "standard" TOML formatting, it comes from a specific extension.

[joshka]

Yeah I use https://marketplace.visualstudio.com/items?itemName=tamasfe.even-better-toml in most projects and often forget to turn it off when viewing other projects. Apologies.

I removed the wrapping changes, but left the spacing changes as they are consistent with the rest of the file. I hope that's ok. If not I can remove those too.

[hds]

OK, I wrote a test for the case as per the documentation, and it fails:

#[test]
fn empty_string() {
    let filter: EnvFilter = ""
        .parse()
        .expect("filter should parse");
    let (collector, finished) = collector::mock()
        .event(expect::event().at_level(Level::ERROR))
        .only()
        .run_with_handle();
    let subscriber = collector.with(filter);

    with_default(subscriber, || {
        tracing::trace!("this should be disabled");
        tracing::debug!("this should be disabled");
        tracing::info!("this should be disabled");
        tracing::warn!("this should be disabled");
        tracing::error!("this shouldn't be disabled");
    });

    finished.assert_finished();
}

But it fails because nothing is received by the collector, it's interpreting an empty string as OFF.

[joshka]

Intuitively (to me at least), empty should effectively be a noop, which for a filter probably means just default. That said, I have a vague recollection there's a bit of weirdness where if the envfilter feature is not enabled you get info level logs by default, but it changes to error level if enabled. That also seems a bit counterintuitive. (I may be misremembering and I'm not near my computer for a few days to check)

[kaffarell]

This is the result of calling EnvFilterBuilder::parse(). There's nothing more to it than that.

Oh you're right, my bad, I tested with EnvFilter::new().

This behavior is kind weird though. We set a default_directive (with min level ERROR) on the new() method, but nowhere else... I think we should remove the default_directive from the new() method – that will make everything more predictable and easy to use. That will be a breaking change though.

[joshka]

Rebased, removed the inferno dep bump, fixed the manifest formatting.
I'm going to make the flow a bit clearer though before it's ready.

[hds]

This looks great. Thank you!