-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Add word-wrap support, with wrap length provided by the user #1119
Conversation
How does this look?
|
I see you just force pushed, so I'm not sure what changed? Can you re-request my review when this is ready for eyes again, and please not force push until after the PR is ready to merge? |
Sorry about that- I squashed the commit in an attempt to make it easy to verify that no new modules were added. I have re-pushed the branch with the original commit followed by a fixup that removes the newly added module. |
I'll try to give this a look soon! |
@lynncyrin Would love to see this merged. |
Oops 😄 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have 1 blocking question, since I'm not following the template.go
changes @mostynb
Is this ready to be merged? |
It's stalled, waiting for review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the contribution!
This is a sweet feature, just had a few minor comments.
@@ -4,16 +4,16 @@ package cli | |||
// cli.go uses text/template to render templates. You can | |||
// render custom help text by setting this variable. | |||
var AppHelpTemplate = `NAME: | |||
{{.Name}}{{if .Usage}} - {{.Usage}}{{end}} | |||
{{$v := offset .Name 6}}{{wrap .Name 3}}{{if .Usage}} - {{wrap .Usage $v}}{{end}} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like we're wrapping most of the fields in the template, but not all of the fields. This PR also omits wrapping for command help and sub-command help.
Is there a reason NOT to expand wrapping to all sections of all templates?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mostly because I don't know all the variations that need to be tested. I suspect there will be some fields that aren't worth trying to wrap because they're only a problem in unusual cases, but command and sub-command help are worth supporting.
I will try to expand this a bit.
I was looking into the conflicting files, and noticed that #1175 has landed, which implements a subset of the feature here. I locally tested a squashed version of this with two fixes appended, which makes How should we proceed? |
@mostynb Are you up for resolving the conflicts and moving this work forward? No worries if not. I'm happy to pick it up ❤️ |
I'll take a look and let you know if I run into trouble. |
d193e40
to
5dcce36
Compare
@meatballhat: the failing test also fails for me locally on the tip of main. The CI failure is also visible in this typo fix PR: #1402 |
@mostynb this looks like the problem of the docs tests running against latest release instead of current working tree 😩 bumping the priority of that work now... |
We could try to automatically detect the terminal width and wrap at that point, but this would increase the binary footprint for all users even if not using this feature. Instead, we can allow users to specify their preferred line length limit (if any), and those who want to bear the cost of checking the terminal size can do so if they wish. This also makes the feature more testable. Original patch by Sascha Grunert <sgrunert@suse.com>
@meatballhat: CI is green after rebasing on main. |
"offset": offset, | ||
} | ||
|
||
if customFuncs["wrapAt"] != nil { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it is better to define a type for this function signature.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not quite sure what you mean- are you suggesting that we export a WrapAtFunc
type alias, and then only use customFuncs["wrapAt"]
if it is created as a WrapAtFunc
explicitly?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Gentle ping on this :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes correct
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This requires some boilerplate for the caller, but I'm not sure how it makes things better. How does this help? I couldn't find any examples of this pattern in a quick web search, but I'm not sure what to call this so maybe I'm missing something obvious.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fwiw I'm happy to defer resolution of this to a later PR, so I'm going to move forward with merging the current work 👍🏼
Is there any docs for this? |
Perhaps it could be more discoverable, but you need to set HelpPrinterCustom or HelpPrinter to add a |
What type of PR is this?
What this PR does / why we need it:
The help text is difficult to read when the lines are long. This patch attempts to wrap long lines, if the user provides a terminal width to wrap at.
Which issue(s) this PR fixes:
Updated version of #1044.
Refers to #287.
Testing
Added a unit test (which can be expanded).
Release Notes