clap suggests hidden subcommands in "similar subcommand" error hints

[yshui]

Please complete the following tasks

• I have searched the discussions
• I have searched the open and rejected issues

Rust Version

irrelevant

Clap Version

master

Minimal reproducible code

fn main() {
    clap::Command::new("app")
        .subcommand(clap::Command::new("subcommand").hide(true))
        .get_matches();
}

Steps to reproduce the bug with the above code

cargo run -- su

Actual Behaviour

error: unrecognized subcommand 'su'

  tip: a similar subcommand exists: 'subcommand'

Expected Behaviour

nothing is suggested.

Additional Context

No response

Debug Output

No response

[yshui]

Fix in #4852

[epage]

Can you give your use case as to why you expect hidden subcommands to be not suggested?

The exact semantics of hide come up from time to time. For example, we suggest hidden subcommands and arguments in completions (#1335). In the new completion system, the proposal is to not suggest completing hidden items by default but to instead complete them if it looks like the user is intending to use the hidden item (#3951).

This latter case sounds similar to suggestions in errors which runs counter to this issue / #4852 which is why this merits further discussion.

[yshui]

so the tool I am working on has commands that is not intended to be run manually, at all. they are only intended to be invoked internally by the tool itself.

i am ok with only suggesting them when the user do intend to use them, but i don't see how you can reliably detect user intentions.

i found this to be a problem because clap suggested things like __subcommand when i typed sub.

[yshui]

maybe there can be two levels of hidden-ness? like, hidden and hidden hidden

[weihanglo]

With #5075, we have UnknownArgumentValueParser to guide users to use the correct flag. If clap provides a way to stop typo-suggesting a flag, it would be perfect!

[Carreau]

I was curious and tried to find a way to do so in #5097.

It adds .didyoumean(false) that filter out arguments from the suggestion logic. In combination with .hide(...) I think that would create what @weihanglo wants and we can extends for subcommands for @yshui.

Anyway just a suggestion instead of fighting for wether or not hide(...) should suggest or not.

[epage]

I think that would create what @weihanglo wants

There was more discussion in rust-lang/cargo#11702 and it is unclear what we want the behavior to be in that case.

Anyway just a suggestion instead of fighting for wether or not hide(...) should suggest or not.

Except this shifts the discussion to whether this part of the API pulls enough weight to justify itself. We've been focusing recently on shrinking clap, in binary size, in compile time, and in API size. The bigger the API is, the harder it is to find anything, making it less likely people will use any of the features in the API, lowering the value gained by having each piece of the API.