Implement tab autocomplete for ruff config

[mishamsk]

Summary

Not the most important feature, but hey... was marked as the good first issue ;-) fixes #4551

Unfortunately, looks like clap only generates proper completions for zsh, so this would not make any difference for bash/fish.

Test Plan

Run all tests & checks per CONTRIBUTING.md and also did a manual test by sourcing target/debug/ruff generate-shell-completion zsh

[github-actions]

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

Formatter (stable)

✅ ecosystem check detected no format changes.

Formatter (preview)

✅ ecosystem check detected no format changes.

[dhruvmanila]

Thank you for working on this!

I'm seeing this entry at the end of the completion list after I press Tab at the end of ruff config :

[mishamsk]

@dhruvmanila

updates:

• fixes the erroneous strings at the end of completions (apparently clap has issues with double quotes in help strings, fails to properly escape them => I replaced with single quotes)
• removed sets from completions that do not have doc. Even though it would be valid to call config with them, I do not see additional value in polluting the completion. In real-life zsh would "stop" at them anyway, albeit with a trailing dot
• as described above, I've switched to passing the entire first paragraph as help string. Doesn't fix the fact that zsh truncates the help to screen width, but probably better than hard-truncation I had before

[dhruvmanila]

• removed sets from completions that do not have doc. Even though it would be valid to call config with them, I do not see additional value in polluting the completion. In real-life zsh would "stop" at them anyway, albeit with a trailing dot

Are you referring to the header like lint.pyupgrade, lint.ruff, etc. as is in my screenshot above? If so, we should include them even though they don't have documentation because ruff config lint.ruff will list out all the config options:

$ ruff config lint.ruff
parenthesize-tuple-in-subscript
extend-markup-names
allowed-markup-calls

[mishamsk]

• removed sets from completions that do not have doc. Even though it would be valid to call config with them, I do not see additional value in polluting the completion. In real-life zsh would "stop" at them anyway, albeit with a trailing dot

Are you referring to the header like lint.pyupgrade, lint.ruff, etc. as is in my screenshot above? If so, we should include them even though they don't have documentation because ruff config lint.ruff will list out all the config options:

$ ruff config lint.ruff
parenthesize-tuple-in-subscript
extend-markup-names
allowed-markup-calls

Yes. Here is why I think there is no point in including them. The whole purpose of completion is to allow a user to get to detailed configuration field description without guessing its name.

Configuration field groups, like lint.isort do not have any associated documentation, and ruff config just falls back to showing list of possible subkeys/fields. But with auto-completion, there is now no need to run ruff config lint.isort, pressing the tab gives even better output than running the command.

See, how the flow looks at the current commit. I first run ruff config lint.isort, and then do double-tab instead:

Now, here is how tab completion will look if I remove the filter:

I am not sure if the first line is helpful. Even if I add something like Lists all available config fields or subconfig keys - why would anyone care auto-completing to that name if they already have the full list with available on screen?

An important note - if lint.isort would get a doc of its own, it will appear in the list. So not all of the config groups are skipped.

tl;dr; I am happy to remove the filter if you think this is how it is supposed to be, but imho the current behavior gets users to where they actually want with slightly less confusion.

[dhruvmanila]

Thanks for providing your thoughts on this. I agree that it might be quicker for a user to get to a specific config key if we skip the plugin header but those are the possible values that can be passed to the ruff config command and I don't think completion list should filter out certain values based on usages. This logic also seems to rely on the fact that the plugin headers doesn't have documentation but it might in the future which means that the suggestions would start including them. It might be that you and I don't use or find it useful but there might be valid use cases that we aren't seeing and users might find it confusing that a possible value is not being suggested. Does that make sense?

[MichaReiser]

I think it's fine to ignore tables as long as we ignore all table entries because you can't set the table itself (I guess you can, but it's somewhat useless).

[dhruvmanila]

I think it's fine to ignore tables as long as we ignore all table entries because you can't set the table itself (I guess you can, but it's somewhat useless).

I see, I'm not sure if that kind of heuristics exists, maybe it does within the OptionsMetadata? Regardless, I'm not sure I follow what you mean by "you can't set the table itself" as, from what I understand, ruff config is mainly to display the documentation of the option or list down all available options for a plugin. Are you referring to a possible future extension of ruff config set?

[dhruvmanila]

What's the reason for having a nested module within the module itself? Should we instead rename this file to completion.rs instead? This will involve updating the lib.rs and args.rs to use the correct name as well.

[mishamsk]

oh, yes, my bad. I originally copied the inner module from RuleSelector, but you are totally right this doesn't make sense here as there is nothing else in the module. I'll fix that alongside the OptionsSet completions as soon as we'll align on what we are doing

[mishamsk]

@MichaReiser as per my logic above - when an OptionSet has some documentation, it is kinda helpful to see it among completions...but tbh only when the set is small and this option even fits on the screen.

So there are two viable alternatives to resolve this:

1. As @dhruvmanila suggested, show all valid values for the command. In that case, I suggest keeping doc for OptionSet's that have them AND adding "Show all available subconfig keys" for those that do not

2. As @MichaReiser suggest filter all OptionSet's from the result and keep only the fields

I'll follow your lead folks, let me know.