-
-
Notifications
You must be signed in to change notification settings - Fork 133
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
Multiple subparsers leads to recursive variables #72
Comments
Forgot to say, I just upgraded to the latest and greatest from pip, 0.6.7, |
Yeah, nested subparsers behave weirdly. When I looked into it, I found that figuring out which subparsers are eligible to receive the next word is really hard, so for now I just throw all subparsers that I can find into the mix of active parsers. If you have a better way to determine active subparsers, by all means please submit a patch. The relevant code is in https://github.com/kislyuk/argcomplete/blob/master/argcomplete/__init__.py#L189. |
I tried this out and it seems to be fixed. I used version 1.6.0
This looks like correct behavior to me and seems to be inline with what argparse is expecting. |
Thanks for verifying, @bbejot. |
@bbejot Would you like to submit a PR for a test case that verifies this? If not I'll add one when I get around to it. |
If you go one subparser deep, into the local branch, this works as expected. Once you fill out zzz or aaa, you're no longer offered autocomplete choices.
If you go into the lookup branch and hit the second subparser, the subparser choice is presented to you as many variables deep as you care to go.
e.g.
Interestingly, if a non subparser argument is added before the inital one, you get offered the correct choices mostly (when you hit a,b,c you get env and etc in the options as well, if you pick a, b, or c completion works properly from then on, but if you choose etc or env, it goes back into looping forever).
The text was updated successfully, but these errors were encountered: