-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Release 0.9.7 #321
Release 0.9.7 #321
Conversation
Is this a temporary workaround? I would prefer if we had clearer priorities for which help gets displayed, i.e. (highest prio: 1, lowest: 4)
|
I consider this to be a solution, but I can be persuaded otherwise :) Priorities are not helping with a situation where you want to have a doc comment for some other purpose but don't want to add any Let's consider scenarios 1..4 Currently 1 and 2 are not supported at all: the only requirement for Adding support for 1 is not a breaking change, adding support for 2 is. Currently 3 is not supported and 4 serves a slightly different role. This comment will show up both when you call your app with To summarize
|
Ah you're right 1 and 2 are both ignored The only reason why that would be nice to have is for consistency: struct Options {
#[bpaf(flag, help("flag is doing this")]
flag: bool,
#[bpaf(argument, help("arg is doing that")]
arg: String,
#[bpaf(external, help("foo is doing foo stuff")]
foo: Foo
} But looking at it, its also annoying to add that foo help in multiple places (e.g. if foo is a group). I think if we get just 3 working i can work with that. This The other issue #319 was about documenting "groups of groups"
I think i can solve this by just adding |
I'll try to add it shortly.
I thought about it, but this means also specifying
In one case doc comment is treated as a group help, in the other case - it's a description. FWIW I added it here: #150 |
#[derive(Debug, Clone, Bpaf)]
#[bpaf(command, help("help attribute on command"))] // <- 3
/// help docs on command // <- 4
struct Foo; FWIW 4 creates something like this: pure(Foo).descr("help docs on command").to_options().command("foo") command will fallback on embedded option parser for documentation, but not the other way around. While 3 will generate something like this: pure(Foo).to_options().command("foo").help("help docs on command") You'll have to use something like this to get it to work #[derive(Debug, Clone, Bpaf)]
#[bpaf(command, descr("help attribute on command"))]
struct Foo; |
I guess that's fine |
It should be possible even in the current version. I'm adding tests for this just in case. |
You can now pass descr, header, footer and help annotations, they will take priority over values derived from doc comments ``` /// those are options struct Opt; ```
@ysndr I added support for (3) overriding (4), test are passing. Can you check if it solves your problem? |
Seems to work, thanks! The only thing I'm still confused with (no a regression of this PR) is formatting newlines:
|
If we are talking about rustdoc comments, not If behavior is different from describing - it's a bug and I'll fix it :) Will look into that. |
#[bpaf(ignore_rustdoc)]
descr
,header
,footer
andhelp
top level annotation forcommand
andoptions
Now you can tell
bpaf
to ignore rust doc comments