feat(level): add off, debug, and trace options for default Level

[pitoniak32]

add example for chaning the default, and mention in the docs

See #10 for some prior discussion

[epage]

In #10, we talked about how to handle --quiet but neither the code nor the description addresses this.

[pitoniak32]

I added the suggestion of hide

value_parser that is assigned to a function that conditionally returns UnknownArgumentValueParser when L::default().is_none()

For this one I looked around the docs, and am not very familiar with clap value parsers, or how to use them conditionally in conjunction with actions. I can keep investigating this, I just wanted to address the other items first, and maybe get some guidance here.

[epage]

This would be something like:

fn default_value_parser::<L: LogLevel>() -> clap::builder::ValueParser {
    if L::default().is_some() {
        clap::builder::UnknownArgumentValueParser::suggest("'--quiet' is the default").into()
    } else {
        clap::builder::value_parser!(u8).into()
    }
}
...
#[arg(value_parser = default_value_parser::<L>())]

Still not entirely sure its the right call to make but starting with an error is the safer choice as we can stop erroring without a breaking change but to start erroring is a breaking change.

Hmm, maybe instead we should make LogLevel in charge of this. If we provide inherent impls, then its generally recognized as not a major breaking change.

This would instead look like

pub trait LogLevel {
    // ...

    fn hide_quiet() -> bool {
        Self::default().is_none();
    }
    fn hide_verbose() -> bool {
        false
    }
    fn quiet_value_parser() -> bool {
        if L::default().is_some() {
            clap::builder::UnknownArgumentValueParser::suggest("'--quiet' is the default").into()
        } else {
            clap::builder::value_parser!(u8).into()
        }
    }
    fn verbose_value_parser() -> bool {
        clap::builder::value_parser!(u8).into()
    }
} 

[epage]

Non-blocker: in the future

• Please create new issue, rather than hijacking an issue
• Please keep your commits atomic. This PR has three separate changes in one commit (tweaked documentation, adding an example with a call out to it, the trace levels)

[pitoniak32]

• Please create new issue, rather than hijacking an issue

Apologies, I am new to making contributions to projects. I will note this for the future 👍🏼

• Please keep your commits atomic. This PR has three separate changes in one commit (tweaked documentation, adding an example with a call out to it, the trace levels)

Sorry about that, I am getting bad commit habits from work. I have separated my commits in this PR.

I have addressed all but one of the concerns, I am planning on continuing to look into how to conditionally disable a flag with the suggested approach.

[epage]

Apologies, I am new to making contributions to projects. I will note this for the future 👍🏼

It is definitely a different world to get used to on-board to faceless projects like this. Best way is to try and see what works. Glad you are here trying!