feat(help): Open the door for user styling in the future #4114
Conversation
This added about 10 KiB to the `.text` which I cannot explain why
This added about 4 KiB to `.text` which makes sense since we duplicated logic.
The immediate benefit is binary size but this also makes us more flexible on the implementation, like allowing wrapping of `StyledStr`. This removed 12 KiB from `.text` This helps towards clap-rs#1365 and probably clap-rs#2037
This dropped us about 1.8 KiB
This adds about 5 KiB to `.text`
While this doesn't reduce size, it cleans things up to make it easier
This ended up favoring the help implementation
Hi @epage, I would be interested in hearing why the I've also implemented wrapping of styled Markdown text in the past: mgeisler/textwrap#140 (comment), which might have come in handy for you. |
| //! Fork of `textwrap` crate | ||
| //! | ||
| //! Benefits of forking: | ||
| //! - Pull in only what we need rather than relying on the compiler to remove what we don't need |
There was a problem hiding this comment.
Are you not already using the optional Cargo features in Textwrap? As per the documentation, every Textwrap dependency is optional.
There was a problem hiding this comment.
I'm not referring to textwrap's optional depednencies but the more general behavior which has more code to it.
|
Its not clear how Our use case is more like the markdown example. We have spans of formatted text and newlines may appear anywhere within it. The markdown example feels complicated/brittle/non-obvious. I think I'd prefer our incremental splitting option over that. |
This mostly makes it so we can implement the following without breaking changes
template#1433In addition, we fixed a bug where the help version of an arg didn't match the usage.
Binary size went from 562.7 KiB to 565.7 KiB. This both added a lot to the size but also reduced it. A large part of the removal came from removing the textwrap dependency, using only what we need which will hopefully help with #2037. We needed to do this anyways because we needed a way to incrementally wrap text so we could wrap a
StyledStr.In general, the code is much simpler, more flexible, and has less duplication that needed to be kept in sync.