Make shell completion prioritize option values over new options

[spanglerco]

Swap the order of checks in _resolve_incomplete so that we first check to see if we're completing an option value before detecting if we're completing a new option name. Allows option values that start with non-alphanumeric characters to complete rather than treating them like new options.

• fixes Shell completion fails for option values that start with symbols #2040
• related to Fix shell completion for arguments with non-alphanumeric characters #1930

Checklist:

• Add tests that demonstrate the correct behavior of the change. Tests should fail without the change.
• Add or update relevant docs, in the docs folder and in code.
• Add an entry in CHANGES.rst summarizing the change and linking to the issue.
• Add .. versionchanged:: entries in any relevant code docs.
• Run pre-commit hooks and fix any issues.
• Run pytest and tox, no tests failed.

[davidism]

How does this affect options without values?

[spanglerco]

How does this affect options without values?

Flag options are unaffected (_is_incomplete_option returns False early if is_flag).

Count options do end up unintentionally taking over the completion for the next arg. That could be easily fixed by extending the previously mentioned is_flag check to if param.is_flag or param.count.

Are there other kinds of options without values? Those are the only two cases I've seen in the documentation.

[spanglerco]

Ah, I guess there's also options with optional values. This change also makes them claim the next arg for completion. If I understand correctly, the parser collects all of the possible prefixes from each option and then decides whether an arg is an optional value vs. another option based on those prefixes.

Should the shell_completions do the same, using the collected prefixes from the parser?

[spanglerco]

@davidism I pushed a rewrite of the fix to instead grab the opt_prefixes from the parser and store them into the context. Then the shell completion can use that information to more closely match what the parser will do.

How does this affect options without values?

The new implementation should treat them the same as the parser: if the incomplete string starts with a symbol used by any of the options, it will complete as a new option. Otherwise, it will complete as the value of the current option. See the added tests in test_shell_completion.py.

[spanglerco]

Hi @davidism is there any interest in this PR or anything else I could help answer about it?