wrap could return an iterator

[mgeisler]

The wrap method currently returns Vec<String> but it could return an iterator instead. This would make it possible to output a large help text line-by-line and do less allocations.

However, if wrap is mostly called through fill, this might not really improve anything since fill still needs to copy the data into a new string.

[mgeisler]

Fixed by #79.

[Lokathor]

There doesn't seem to be an iterator based portion of the crate any more :(

[mgeisler]

Hey @Lokathor, you're right. The iterator conflicted with the full-paragraph wrapping I implemented a while ago: instead of looking at the text word-by-word, the algorithm looks at the entire paragraph and finds globally optimal break points for it.

My expectation is that most strings are fairly small, so do you have a use-case where it's too expensive to keep a full Vec<Cow<str>> in memory together with the input &str?

[Lokathor]

Naw it's a terminal program for desktop usage (a text game), so it's not too expensive in terms of space or speed. I just always look for the iterator version of stuff first and was sad to see that this iterator had disappeared at some point in the versioning.

[mgeisler]

I just always look for the iterator version of stuff first and was sad to see that this iterator had disappeared at some point in the versioning.

Yeah, I think it would be nice to support iteration, but it conflicts with wrap_optimal_fit, which produces all wrapped lines at the same time.

Or rather: I guess an iterator could be added, with the understanding that you will be iterating over lines which are already formed in memory. The iterator could make sense for wrap_first_fit, since that function can produce output line-by-line.

At a high level, I would be more interested in implementing #224, which is about wrapping while keeping state. So you could imagine feeding in text piece by piece and then getting the wrapped lines back in smaller chunks as well.