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

[almas-x]

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.

[abitrolly]

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

[almas-x]

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]

@almas-x Thanks for the PR. I looked at https://github.com/goravel/framework/pull/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]

@almas-x Thanks for the PR. I looked at https://github.com/goravel/framework/pull/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]

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 https://github.com/urfave/cli/issues/1607 so that it won't be specific to functional cli API.

[dearchap]

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

[almas-x]

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.