Skip to content

Export help display functions as variables to allow custom help display logic #2150

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

Merged
merged 2 commits into from
Jul 13, 2025

Conversation

almas-x
Copy link
Contributor

@almas-x almas-x commented Jun 5, 2025

What type of PR is this?

  • feature

What this PR does / why we need it:

  • Exported ShowAppHelp, ShowCommandHelp, and ShowSubcommandHelp as variables assigned to private functions.

  • This allows users to override the help display logic for the app and commands, improving extensibility and flexibility for custom help behaviors.

Release Notes

(REQUIRED)

Exported `ShowAppHelp`, `ShowCommandHelp`, and `ShowSubcommandHelp` as variables assigned to private functions, allowing users to override help display logic for custom behaviors.

@almas-x almas-x requested a review from a team as a code owner June 5, 2025 06:27
@almas-x almas-x changed the title feat: export ShowCommandHelp and ShowSubcommandHelp as variables for user override feat: export ShowAppHelp, ShowCommandHelp, and ShowSubcommandHelp as variables to allow custom help display logic Jun 5, 2025
@almas-x almas-x changed the title feat: export ShowAppHelp, ShowCommandHelp, and ShowSubcommandHelp as variables to allow custom help display logic feat: export help display functions as variables to allow custom help display logic Jun 5, 2025
@abitrolly
Copy link
Contributor

Is there something that is impossible with the current API/templates?

@almas-x
Copy link
Contributor Author

almas-x commented Jun 5, 2025

Is there something that is impossible with the current API/templates?

The readability of Go templates is quite poor, which makes debugging difficult. Additionally, they are not flexible enough to support more advanced customization, such as using colors to distinguish between commands, flags, and so on. While it is possible to add custom functions to templates by defining a custom printer function, this approach is hard to maintain. For examples of more personalized requirements, please refer to @goravel/framework/pull/766.

@dearchap
Copy link
Contributor

dearchap commented Jun 5, 2025

@almas-x Thanks for the PR. I looked at goravel/framework#766 . It seems to me you could have been best served by setting HelpPrinterCustom to your printHelperCustom ? Yes you would still be doing the hard work and you dont need to have cli library export the ShowAppHelp and everything right ?

@almas-x
Copy link
Contributor Author

almas-x commented Jun 5, 2025

@almas-x Thanks for the PR. I looked at goravel/framework#766 . It seems to me you could have been best served by setting HelpPrinterCustom to your printHelperCustom ? Yes you would still be doing the hard work and you dont need to have cli library export the ShowAppHelp and everything right ?

In goravel/framework#766, we replaced HelpPrinterCustom. However, as I mentioned earlier, Go’s template is difficult to read, maintain, and adapt for i18n. This makes it challenging to handle localization effectively. That’s why I propose exporting ShowXXXHelp for directly formatting and printing the help information. By avoiding template rendering, this approach is more intuitive, flexible, and better suited for addressing localization needs.

@abitrolly
Copy link
Contributor

How people are going to discover what is available in cmd object to produce help?

It would be nice to have some page listing all variables/props used. Maybe render them from JSON #1607 so that it won't be specific to functional cli API.

@dearchap
Copy link
Contributor

dearchap commented Jun 7, 2025

I'm still not convinced having this would have helped @almas-x . Maybe I'm missing something .

@almas-x
Copy link
Contributor Author

almas-x commented Jun 7, 2025

I'm still not convinced having this would have helped @almas-x . Maybe I'm missing something .

Perhaps I didn’t express myself clearly. My point is to export these ShowXXXHelp methods so that when printing help information, we can directly use something like fmt.Sprintf within these methods for output, instead of relying on template rendering. This way, it allows for i18n handling or adding color formatting before fmt.Sprintf, reducing the limitations compared to templates. If you still feel this doesn’t add much value, please go ahead and help close this PR.

@meatballhat meatballhat added kind/feature describes a code enhancement / feature request area/v3 relates to / is being considered for v3 labels Jun 14, 2025
@meatballhat meatballhat changed the title feat: export help display functions as variables to allow custom help display logic Export help display functions as variables to allow custom help display logic Jun 14, 2025
@almas-x almas-x closed this Jun 16, 2025
@almas-x almas-x reopened this Jun 23, 2025
@dearchap dearchap merged commit 9cd5d9c into urfave:main Jul 13, 2025
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/v3 relates to / is being considered for v3 kind/feature describes a code enhancement / feature request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants