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

Separate help texts for subcommands that are internally implemented as aliases #1523

Open
smithfarm opened this issue Mar 15, 2024 · 1 comment
Labels
Deferred To be implemented in the future. Frequently waiting on other changes to happen first. Documentation Feature

Comments

@smithfarm
Copy link
Member

smithfarm commented Mar 15, 2024

Is your feature request related to a problem? Please describe.

When users issue --help for an osc subcommand that is internally implemented as an alias, they get a wall of text, most of which might seem completely unrelated to the osc subcommand they are interested in. Users are forced to sift through this text to find the bits that relate to the subcommand for which they asked for help.

Describe the solution you'd like

The output of osc foo --help should only pertain to foo, and not to any other subcommands, even if foo is internally implemented as an alias.

Describe alternatives you've considered

None.

Additional context

A classic example is the help text displayed when the user issues the command osc shell --help. Since shell is internally an alias of build, the users get the whole help text for build and are forced to read through all of it to find the shell bits they are interested in.

@smithfarm smithfarm changed the title Separate help texts for commands that are internally implemented as aliases Separate help texts for subcommands that are internally implemented as aliases Mar 15, 2024
@dmach
Copy link
Contributor

dmach commented Apr 8, 2024

This requires massive refactoring of the commands.
Keeping in backlog as a reminder, because we definitely want osc to move in this direction.

@dmach dmach added the Deferred To be implemented in the future. Frequently waiting on other changes to happen first. label Apr 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Deferred To be implemented in the future. Frequently waiting on other changes to happen first. Documentation Feature
Projects
None yet
Development

No branches or pull requests

2 participants