This version of textwrap uses a new wrapping algorithm that allocates
fewer strings on the heap.
The 05_ripgrep benchmarks shows a performance improvement of 3-15%.
The build_help_long benchmark benefits the most since it uses longer
help texts.
All the other features are either irrelevant, for nightly or already included by default so this should build with all features.
https://github.com/onur/docs.rs/pull/73Fixes#911
* chore: disables mention-bots finding reviewers and pinging tons of people
* docs(README.md): added a warning about using ~ deps
* chore: increase version
The textwrap crate uses a simpler linear-time algorithm for wrapping
the text. The current algorithm in wrap_help uses several O(n) calls
to String::insert and String::remove, which makes it potentially
quadratic in complexity.
Comparing the 05_ripgrep benchmark at commits textwrap~2 and textwrap
gives this result on my machine:
name before ns/iter after ns/iter diff ns/iter diff %
build_app_long 22,101 21,099 -1,002 -4.53%
build_app_short 22,138 21,205 -933 -4.21%
build_help_long 514,265 284,467 -229,798 -44.68%
build_help_short 85,720 85,693 -27 -0.03%
parse_clean 23,471 22,859 -612 -2.61%
parse_complex 29,535 28,919 -616 -2.09%
parse_lots 422,815 414,577 -8,238 -1.95%
As part of this commit, the wrapping_newline_chars test was updated.
The old algorithm had a subtle bug where it would break lines too
early. That is, it wrapped the text like
ARGS:
<mode> x, max, maximum 20 characters, contains
symbols.
l, long Copy-friendly,
14 characters, contains symbols.
m, med, medium Copy-friendly, 8
characters, contains symbols.";
when it should really have wrapped it like
ARGS:
<mode> x, max, maximum 20 characters, contains
symbols.
l, long Copy-friendly, 14
characters, contains symbols.
m, med, medium Copy-friendly, 8
characters, contains symbols.";
Notice how the word "14" was incorrectly moved to the next line. There
is clearly room for the word on the line with the "l, long" option
since there is room for "contains" just above it.
I'm not sure why this is, but the algorithm in textwrap handles this
case correctly.
The newly released version 1.2.0 of unicode-segmentation adds code
that use the "?" operator, which in turn requires Rust 1.13.0.
However, clap currently still works with Rust 1.11.0 and this caused
build failures:
https://travis-ci.org/kbknapp/clap-rs/jobs/235010822
The changes since 1.1.0 seem to be related cursors/iterators and I
think clap can work fine without them.
Not only does this remove some unsafe code from clap itself, `atty` does the
right thing on Windows too. This isn't relevant now since we don't currently
support colorized output on Windows, but will come in handy if/when we
implement that feature (#836).
