Fix shell completion for arguments with non-alphanumeric characters

[samschott]

This PR fixes shell completion for arguments with non-alphanumeric characters by implementing a less stringent test in shell_completion._start_of_option().

• fixes Shell completion fails with for arguments starting with "/" #1929

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]

Please rebase to 8.0.x:

$ git rebase --onto origin/8.0.x origin/main
$ git push -f

[davidism]

Please use git rebase -i origin/8.0.x to squash these commits into one (with one commit message, not the combination of all).

[samschott]

All of them, or just the changelog entries?

[davidism]

All of them.

[samschott]

Any comments regarding the actual changes? Am I overlooking some cases by assuming that all options begin with a "-"? There might have been a good reason for the alphanumeric check.

[davidism]

Options can start with any non-alpha character, not only -. Windows tools often use /. The other most common, shown in the docs, is +. Different options can have different prefixes, it doesn't have to be consistent across options or commands.

[samschott]

Ah, yes, I should have red https://click.palletsprojects.com/en/8.0.x/options/#other-prefix-characters 🤦. Apologies for that.

This makes things a bit more difficult. I can see following choices:

1. Keep the code as is and document that shell completion is only supported for values that start with alphanumeric characters. This would be a shame, especially since paths are such a common argument type for command line tools.
2. Collect all possible option prefixes for a specific command. If the incomplete string starts with one of those prefixes, recognise it as the start of an option. This would still prioritise the completion of option names over arguments or option values (as is the case currently), but only if there are actually any option names starting with the given character.

If you agree, I can try to implement the second.

[davidism]

How about just don't support completion of Windows-style options, since that already wasn't supported.

[samschott]

So we would hard-code a set of non-alphanumeric characters that are supported for the shell completion of options? For example {"-", "+"} or just "-" as in this PR?

One advantages of the 2. approach from my the previous comment: if a command has only arguments and no options, we can offer completion for arguments that start with -.

The most rigorous solution probably would be: if the incomplete string starts with a non-alphanum character, we offer completions for both matching options and arguments. This will however be complex to implement, especially when offering completion for both a path and an option.

It's really up to you. As you say in the docs, any prefix other than "-" or "--" for options is discouraged. And the reverse, argument values that start with "-", are quite uncommon. The most probable use case is free string input and shell completion won't be very useful there.

[davidism]

I was thinking not value[0].isalnum() and value != "/"

[samschott]

Ok, done.