Skip to content
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

Argument specification (in usage-line) customization & "smart" default #59

Draft
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

z33ky
Copy link

@z33ky z33ky commented Dec 27, 2023

I find the defaut $argv0 [OPTIONS] is very bare bones.
A custom spec can now be passed using a new arg_spec attribute:

#[derive(Options)]
#[options(arg_spec = "MY [SPEC]")]
struct MyOptions { ... }

Which shows up in the first usage line:

$ target/debug/test
Usage: target/debug/test MY [SPEC]
...

I've also added some smart option detection, so the default spec can now show COMMAND, OPTIONS and ARGS, with a ... if multiple are valid and surrounded by [] if optional.

If you find this useful I will update the documentation and would also add tests before considering this ready to merge.

I would also like to allow more customization, like formatting the strings as command or <command> instead of fixating on the current UPPER_CASE.
My ultimate vision would also allow generation of a "full" command-spec like Usage: $argv0 [-h|--help] [-v] [--file FILE] [-- PATHS...]. This does get unwieldy when a tool has lots of options, so it should definitely be optional. Maybe a user can also tag "important" options to include in the usage-line and leave out the rest.
If I add these I will implement them in separate PRs.

Previously the default arg_spec was just "[OPTIONS]".
Now the string depends on whether command-, name- and free-options are
present, if they are optional and if multiple exist, and can span from
an empty string to "[COMMAND] [OPTIONS...] [ARGS...]".
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant