-
-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Unexpected help text formatting with possible_values and default_value functions #688
Comments
Thanks for putting in all these details! What width is your terminal? And was the terminal the same width/size for both of the above tests? I'm asking because clap automatically does some calculations with terminal width, and decides if the help message is too long for the current line, or would wrap "too much" and therefore adds a newline and indents just past the flags/options (a la, something like This could also be a bug you found; in that clap is doing the math differently if possible values are hidden or not (shouldn't be the case, and would be a bug). I don't want to tag with the bug label until it's confirmed 😉 |
Also, some of the math that goes into determining when to wrap and indent like this is determined by the length of the longest flag/option in comparison with your terminal width, so it may be helpful to see the wrest of the help message. Another thing you could try, and might provide even better info is to compile clap with the i.e. [dependencies]
clap = {version = "2.14.0", features = ["debug"]} Then past the output when running |
The previous examples were run in Terminal.app in fullscreen mode with 141 columns and 36 lines (based on output from the I have turned on debugging, compiled the application and clap, and attached the output for both conditions. The |
fix: fixes a bug that made determining when to auto-wrap long help me… …ssages inconsistent Closes #688
I believe I have found an issue with the automatic formatting for an option using the
possible_values
function.If the following code is used:
The following output is created for the help text:
A new line appears to be inserted and the indention is off. This might be the intended behavior as it looks like the code is attempting to keep the possible values list on the same line. If the following code is used instead, i.e. manually create the bracketed list of possible values and turn off the automatic generation with the
hide_possible_values
function:The following output is created for the help text:
The help text is properly wrapped and on the same line as the option description. Note, I have omitted the rest of the help text and code in the examples for clarity, but the rest of the help text is causing the relatively large gap between the option description and the help text and it is expected.
This is in Terminal.app on Mac OSX El Captian with a MacBookPro Retina. I have not confirmed it for other systems, but I believe I saw a similar behavior on a Windows machine. It is not a huge issue as the workaround can be setting the values manually and turning off automatic generation as in the second example, but the same problem also appears to occur with the
default_value
function and there is nohide_default_value
function equivalent to thehide_possible_values
function.The text was updated successfully, but these errors were encountered: