Skip to content
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

Having a unique display name and an execution name for commands #4642

Closed
2 tasks done
xosxos opened this issue Jan 15, 2023 · 2 comments
Closed
2 tasks done

Having a unique display name and an execution name for commands #4642

xosxos opened this issue Jan 15, 2023 · 2 comments
Labels
C-enhancement Category: Raise on the bar on expectations

Comments

@xosxos
Copy link

xosxos commented Jan 15, 2023

Please complete the following tasks

Clap Version

4.1.1

Describe your use case

I am using klask to generate egui applications directly from clap. This allows me to turn cli applications into native gui apps or webapps for people unfamiliar with the command line.

However, I find that the names for subcommands benefit from a longer more descriptive name in the GUI app and on the contrary CLI apps should use shorter names with hyphens which are easier to type out.

I tried implementing Display for the subcommand enum, but noticed the macro creates a Commands which I cannot implement a custom display for. Thus, it seems I am stuck with only a single name for each command.

Describe the solution you'd like

This way I could use abbreviations for the cli applications, but the full names for gui applications.

#[derive(Debug, Parser)]
pub enum Subcommand {
    #[command(name = "mcsf", display_name = "My Special Command Function")]
    MSCF {},
    #[command(name = "subcommand-a", display_name = "Subcommand A")]
    SubcommandA {},
}

Alternatives, if applicable

No response

Additional Context

No response

@xosxos xosxos added the C-enhancement Category: Raise on the bar on expectations label Jan 15, 2023
@epage
Copy link
Member

epage commented Jan 16, 2023

The problem with this is we have nowhere else to use this display name within clap.

A workaround is we are exploring the idea of a plugin system where Command, Arg, etc effectively have an AnyMap so the user can attach any data they want and any library on top of clap can read it. An easy example of this is clap doesn't care about ValueHint but clap_complete does so we should move it out.

Our main priority atm is styling of help and errors. Next is either the plugin system or wrapping up some ArgGroup work.

@epage
Copy link
Member

epage commented Jan 31, 2023

Without further input, I'm closing this in favor of the future plugin system.

@epage epage closed this as not planned Won't fix, can't repro, duplicate, stale Jan 31, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-enhancement Category: Raise on the bar on expectations
Projects
None yet
Development

No branches or pull requests

2 participants