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

Add ArgPrecedenceOverSubcommand app setting #1834

Merged

Conversation

davidMcneil
Copy link
Contributor

ArgPrecendenceOverSubcommand is an app setting that changes if argument values should be greedily consumed instead of stopping when a subcommand is encountered. See #1721 for further explanation. See #1031 and 0c223f for when the initial change was made.

There should probably be further community discussion on the correct default.

Signed-off-by: David McNeil [email protected]

@davidMcneil davidMcneil force-pushed the arg_value_precedence_over_subcommand branch from 4f63e28 to 247231d Compare April 16, 2020 14:09
@pksunkara
Copy link
Member

Great PR! The only issue is that I am not convinced we should be changing the behaviour here. I still think we should keep the old behaviour as default.

@davidMcneil
Copy link
Contributor Author

I still think we should keep the old behaviour as default.

That is understandable. I personally prefer this default behavior, but I am happy to change it to SubcommandPrecedenceOverArg if that is the consensus.

I am curious why you prefer the current behavior?

@pksunkara
Copy link
Member

These behaviours are something that are hard to describe and even if we are breaking a lot of stuff for 3.0, this one might be a bit too far and difficult to understand. Basically, I want to be more cautious.

@pksunkara pksunkara self-requested a review April 20, 2020 09:12
Copy link
Member

@pksunkara pksunkara left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Waiting for the change to be SubcommandPrecedenceOverArg

Copy link
Member

@pksunkara pksunkara left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

bors r+

@bors
Copy link
Contributor

bors bot commented Apr 20, 2020

🕐 Waiting for PR status (Github check) to be set, probably by CI. Bors will automatically try to run when all required PR statuses are set.

@pksunkara
Copy link
Member

bors r+

Copy link
Contributor

@CreepySkeleton CreepySkeleton left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Apart from this, looks good!

src/build/app/settings.rs Outdated Show resolved Hide resolved
Copy link
Contributor

@CreepySkeleton CreepySkeleton left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm very sorry for sequential nitpicks, but the indentation...

src/build/app/settings.rs Outdated Show resolved Hide resolved
@pksunkara
Copy link
Member

bors r+

@pksunkara
Copy link
Member

Bors is constantly crashing for this PR. Don't know why. I am manually merging this.

@pksunkara pksunkara merged commit 4911c35 into clap-rs:master Apr 21, 2020
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.

Document that multi-value options do not get along with trailing subcommands
3 participants