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

feat: fields for VisibleFlags name/alias and Usage #2016

Open
2 of 3 tasks
midirhee12 opened this issue Nov 28, 2024 · 6 comments
Open
2 of 3 tasks

feat: fields for VisibleFlags name/alias and Usage #2016

midirhee12 opened this issue Nov 28, 2024 · 6 comments
Labels
area/v3 relates to / is being considered for v3 status/triage maintainers still need to look into this

Comments

@midirhee12
Copy link
Member

midirhee12 commented Nov 28, 2024

Checklist

  • Are you running the latest v3 release? The list of releases is here.
  • Did you check the manual for your release? The v3 manual is here.
  • Did you perform a search about this feature? Here's the GitHub guide about searching.

What problem does this solve?

When customizing the AppHelpTemplate, it would be preferable to change how the first and second column are formatted, ie - the description of the flag on a separate line, tabbed out, and restricted to a width of 80 characters. In the current state of .VisiableFlags, there is no way to separate the two columns beyond a slice of strings. Each flag has its name and description (.Usage) clumped together as a single string which is difficult or nearly impossible to parse using go's template actions.

Solution description

The two columns should be exposed as separate fields.

For the first column, .Name does not truly suffice as it both contains the long Name, Aliases, and has the input values marked by the respective name or alias. A fitting name for this could be .Names or .Flags.

For the second column, something equivalent to .Usage is sufficient.

Describe alternatives you've considered

I've tried to loop through .VisiableFlags and coerce each flag to its original type such as StingFlag and then create a custom template to load which would effectively recreate the first column. But this served to be very tedious, and admittedly, I'm not good enough in golang to do this with ease.

I also thought of potentially hand writing this part of the help template. But this deemed tedious as well and goes against the spirit of urfave/cli as it does not autogenerate based on the visible flags.

@midirhee12 midirhee12 added status/triage maintainers still need to look into this area/v3 relates to / is being considered for v3 labels Nov 28, 2024
@dearchap
Copy link
Contributor

@midirhee12 you could cast the Flag to a DocGenerationFlag to extract further information if you'd like. Admittingly its not elegant but might work ?

@midirhee12
Copy link
Member Author

How would this be casted and used within the AppHelpTemplate?

@midirhee12
Copy link
Member Author

@dearchap From what I know, you would have to map the function into the template before being evaluated. Is there a way this is being exposed?

@midirhee12
Copy link
Member Author

Either way, even if it is possible, I think there should be a more straightforward and clean way to access this since formatting the templates could be quite frequent among users.

@midirhee12
Copy link
Member Author

@dearchap Actually, on second thought. Is it possible to expose .VisibleFlagTemplate and such instead?

@dearchap
Copy link
Contributor

dearchap commented Dec 1, 2024

@midirhee12 yes. you want to make a PR ?

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 status/triage maintainers still need to look into this
Projects
None yet
Development

No branches or pull requests

2 participants