-
-
Notifications
You must be signed in to change notification settings - Fork 1.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
Clap mangles multiline help text #617
Comments
For your case, I believe using the default
|
This looks a bit better, however there are still strange newlines:
|
I think this is a product of the 120 default term width. Try setting |
I get an 'attempt to subtract with overflow' panic at How can it be related to the default term width? The lines are much shorter than that. Does clap ignore Edit: Updating to clap 2.11 fixes the panic and does indeed work. (However, some of the autogenerated text is too long.) The line wraps still don't make sense to me if the term width is not set to 0. |
@vks can you post what it looks like when not set to 0? If there are hard newlines in the help text, clap counts those simply as bytes, and not as newlines which restart the count until the next wrap. This can cause there to be two newlines, the hard one and the one that clap counts and inserts at. |
@kbknapp Now with the new clap version and default term width I'm getting
with
with
Why can't clap just look for newlines and treat them accordingly? |
@vks when I run the example you posted and add
|
They get printed accordingly, but |
@kbknapp Setting the term width to 0 works for me as well, as mentioned in my previous comment. This is a possible workaround, but you lose wrapping. You can just limit the help text to 80 characters and it should look fine on most terminal sizes. However, you have no control over wrapping for example the list of allowed values, which is generated by clap. You can disable its generation and create the list manually though. Only the automatic wrapping of multiline help text is completely broken for me. |
@vks I understand. I'm working the issue as we speak, since this is also an issue for |
@vks Ok, so I've got it to where upon having enough space (i.e. term width is big enough) it will simply ignore the new lines:
But if the term width is smaller, it will wrap.
|
@kbknapp Looks great! This is exactly what I was imagining. |
Just put in the PR, see #650 |
Note, this also removes the requirement to use |
Thanks! |
This adds a test for the issue clap-rs#617 about keeping whitespace intact in manually aligned text.
This adds a test for the issue clap-rs#617 about keeping whitespace intact in manually aligned text.
This adds a test for the issue clap-rs#617 about keeping whitespace intact in manually aligned text.
This adds a test for the issue clap-rs#617 about keeping whitespace intact in manually aligned text.
This adds a test for the issue clap-rs#617 about keeping whitespace intact in manually aligned text.
With this option, whitespace between words can be significant. That is, whitespace added for alignment purposes can be kept in the output. This means that wrapping strings like -v: be very verbose and output lots of messages --foo: inject extra foos in the output --foobar: enable the foobar optimization (if possible) can end up looking like -v: be very verbose and output lots of messages --foo: inject extra foos in the output --foobar: enable the foobar optimization (if possible) Fixes #28. Related to clap-rs/clap#617.
This adds a test for the issue clap-rs#617 about keeping whitespace intact in manually aligned text.
This adds a test for the issue clap-rs#617 about keeping whitespace intact in manually aligned text.
This adds a test for the issue clap-rs#617 about keeping whitespace intact in manually aligned text.
Use my textwrap crate for wrapping help texts This PR replaces the `wrap_help` function with a call to my [textwrap][1] crate which does word wrapping using a simpler and faster algorithm. I've extended the `05_ripgrep` benchmarks with a benchmark that tests generating the help text -- I figured that ripgrep would be a good example since it has lots of long strings in the help output. Comparing before and after looks like this on my machine: ``` name before ns/iter after ns/iter diff ns/iter diff % speedup build_app_long 22,101 21,099 -1,002 -4.53% x 1.05 build_app_short 22,138 21,205 -933 -4.21% x 1.04 build_help_long 514,265 284,467 -229,798 -44.68% x 1.81 build_help_short 85,720 85,693 -27 -0.03% x 1.00 parse_clean 23,471 22,859 -612 -2.61% x 1.03 parse_complex 29,535 28,919 -616 -2.09% x 1.02 parse_lots 422,815 414,577 -8,238 -1.95% x 1.02 ``` I've also added a test for #617 to ensure that the output described there is kept unchanged. That is, textwrap will now by default keep horizontal whitespace when wrapping text and this allows you to do rudimentary formatting in the help text by manually inserting whitespace. [1]: https://crates.io/crates/textwrap <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/kbknapp/clap-rs/845) <!-- Reviewable:end -->
This adds a test for the issue #617 about keeping whitespace intact in manually aligned text.
Consider this example:
The following help will be printed:
It seems like clap randomly inserts newlines. Increasing the terminal size does not change anything.
The text was updated successfully, but these errors were encountered: