Support overrides_with("itself") #976
Comments
kbknapp
added
A-parsing
|
Thanks! I like the |
|
Cool. Actually the POSIX specifications don't state nothing about overriding arguments. But the way the POSIX implementation usually involves a loop through the arguments, same arguments just get a count increment or override the previous assigned one. Maybe the AppSettings could be something more explicit than just |
to better organize options. These are the changes: - color will have default value of "never" if --vimgrep is given, and only if no --color option is given - last overrides previous: --line-number and --no-line-number, --heading and --no-heading, --with-filename and --no-filename, and --vimgrep and --count - no heading will be show if --vimgrep is defined. This worked inside vim actually because heading is also only shown if tty is stdout (which is not the case when rg is called from vim). Unfortunately, clap does not behave like a usual GNU/POSIX in some cases, as reported in clap-rs/clap#970 and clap-rs/clap#976 (having all the bells and whistles, on the other hand). So we still have issues like rg failing when same argument is given more than once (unless for the few ones marked with `multiple(true)`), or having unintuitive precedence rules (and probably non-intentional, just there because of clap's limitations) like: - --no-filename over --vimgrep - --no-line-number over --column, --pretty or --vimgrep - --no-heading over --pretty regardless of the order in which options where given, where the desired behavior would be that the last option would override the previous ones given.
|
There definitely should be an exa just ran into this issue with its argument parsing (which was getopts), and it looks like their solution is to implement a custom argument parser. And it looks like ripgrep also hit this limitation. |
|
This tweet got me thinking about this issue some more, and I'm thinking that because of the new lazy validation I'm doing this could actually be an easy add, and easily forward portable to the v3-master branch. I'm going to take a look at this tomorrow see and if it's as easy as I think it'll be. |
…elves This allows properly supporting shell aliases and config files. Before, if an option only accepted a single value and that option was set inside an alias, the CLI could never override that value. For instance: ``` $ alias prog='prog --option=value' $ prog --option=other ``` This would cause an error. Now clap gracefully accepts the new value to replace the old value. Closes #976
… all args to override themselves Relates to #976
…elves This allows properly supporting shell aliases and config files. Before, if an option only accepted a single value and that option was set inside an alias, the CLI could never override that value. For instance: ``` $ alias prog='prog --option=value' $ prog --option=other ``` This would cause an error. Now clap gracefully accepts the new value to replace the old value. Closes #976
… all args to override themselves Relates to #976
… all args to override themselves Relates to #976
Suppose I have defined these:
I'd like to allow the options to be able to be defined multiple times, the last one overriding previous ones.
So a call with options
--foo --foo --foo --bar=0 --bar=1 --bar=2will not fail witherror: The argument '--foo' was provided more than once, but cannot be used multiple times(or the same for--bar), and both foo, and bar with value 2 would be yield (resulting in the same as calling with only--foo --bar=2).Or even better, maybe a
.setting(AppSettings::POSIX)defined once would enable the previous behavior. Why would defining the same option twice or more yield an error? I just played with some command line tools here (git status --short --short --short,ls -l -l -l,vi -R -R -R README.md) and none complains of options provided multiple times...The text was updated successfully, but these errors were encountered: