1. I agree, it's very verbose and introduces boilerplate code with the getters. Creating a attribute macro like #[bool_arg] unfortunately would require us to create a new crate as shown in the docs, I think this is a current language limitation. Clap could also be configured programmatically instead of using the macros but it probably makes no sense to combine the current attribute approach with a programmatic approach. (LycheeOptions::command().arg(clap::Arg::new("some-bool-arg"))) So it seems like there is no simple elegant solution.
2. I agree that we should treat all bool flags the same.
3. Hmm, from a user-perspective I actually like this PR. I think it's easier to have a single arg which can be set to true/false instead of having different args which affect the same boolean value.

@katrinafyi @mre What are your thoughts?

Thanks @katrinafyi and @thomas-zahner for your feedback. I believe I addressed all your comments. PTAL.

Re the big #[arg] macro attribute, I asked the question in the Rust discord and got this answer (among other, much more complicated macro answers):

I think you could define an extension trait on Arg and call that with arg() syntax

I have no idea if it actually does but can't imagine why it wouldn't

If you want, it's worth a try @cristiklein. The idea is that the #[arg] macro just transforms itself into the builder API. For example, #[arg(num_args = 1] is transformed into the builder syntax as:

arg.num_args(1)

So, if you add an extension method on Arg, it might be able to be invoked the macro.

pub trait ArgExt  {
    fn optional_with_bool_value(self) -> Arg {
        // apply the needed options using the builder API
    }
}

// then later,
#[arg(optional_with_bool_value)]

Great find @katrinafyi and works like a charm. See 2521d07. Help message didn't change at all during refactoring.

@mre I found a few ways to beautify the help message. For example:

            .value_name("false|true") // Set the value name for help messages
            .hide_possible_values(true)
            .default_value("false")

Leads to:

      --suggest[=<false|true>]
          Suggest link replacements for broken links, using a web archive. The web archive can be specified with `--archive`
          
          [default: false]

See 5931004

Arrrgggh, sorry, I pressed ENTER too fast. .default_value("false") has the unintended effect that missing flags become false and not None, which defies the whole point of this PR.

So the best I could obtain was:

            .value_name("false|true") // Set the value name for help messages
            .hide_possible_values(true)

Which leads to:

      --suggest[=<false|true>]
          Suggest link replacements for broken links, using a web archive. The web archive can be specified with `--archive`

Great find @katrinafyi and works like a charm.

Incredible! Honestly I had no idea if it would work. Thanks for doing that, I think it's a bit cleaner :)

@cristiklein @katrinafyi Thank you, that's quite a lot less boilerplate code and quite an improvement!