laxPlacement doesn't allow positional in the middle of two flags

[eight04]

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?

[eight04]

I accidentally pressed Ctrl-Enter :(

[felixSchl]

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

[eight04]

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

[felixSchl]

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

[felixSchl]

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