laxPlacement doesn't allow positional in the middle of two flags
eight04 opened this issue · 5 comments
Currently, laxPlacement option allows us to place flags before or after the positional arguments.
usage: test [-abc] <files>...
These are allowed:
test -a -b file1 file2
test file1 file2 -a -b
But this will fail:
test -a file1 file2 -b
test: unexpected option -b
usage: test [-abc] <files>...
See test -h/--help for more information
I think the third one is also valid. Can we support it?
I accidentally pressed Ctrl-Enter :(
This is only the case for repeating positional arguments as they are expected to appear directly adjacent currently. I think it should be possible to handle this case, I will have to think about the consequences a bit more thoroughly though.
For example:
usage: foo [-abc] a b
parses foo a -a b
Seems that git parse them as well
git remote add [-t <branch>] [-m <master>] [-f] [--tags | --no-tags]
[--mirror=<fetch|push>] <name> <url>
Successfully parsed:
git remote add name --tags url
Neodoc parses that one just as well. Make sure to turn on "smart-options" to transform from [-t <branch>]
to [-t=<branch>]
, meaning that <branch>
is bound to -t
.... I think that's where the confusion comes from.
Sample output:
<name> → "name"
<url> → "url"
add → true
remote → true
--tags → true
Alright, so I was wrong (luckily). Neodoc already supports what you want to do. I apologize for the confusion.
Here is what's happening:
You specify usage: foo [-abc] <file>...
which really means usage: foo [-a -b -c] <file>...
. Here once you start matching into the optional grouping, the grouping gets consumed and removed from the pattern (unless the group is itself repeated: [-abc]...
). You can fix this by doing: usage: foo [-a] [-b] [-c] <file>...
(with opts.requireFlags
) or usage: foo -abc <file>...
(without opts.requireFlags
). If you don't like this format, you can use a pre-transform (for now) to expand this group into 3 top-level flags.
What I did find, however, when experimenting with your usecase, is that: usage: foo [options] <file>...
exposes the faulty behavior you describe. I am looking into that now.
updated w/ more info