You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
textwrap::wrap_algorithm already works with the Fragment trait. What do you think about making the textwrap::word_separators and textwrap::word_splitters modules generic?
As far as I see, it would not even be necessary to introduce a new trait. word_separators::WordSeparator::find_words could accept S: AsRef<str> instead of &str and a function that creates a fragment from S and two indices. word_splitters::split_words could accept W: AsRef<str> and a function that splits W at a given point with or without penalty and hyphen. (There might be some lifetime issues, but I think that should be solvable.)
If you agree on the concept, I can prepare a draft implementation.
The text was updated successfully, but these errors were encountered:
For WordSeparator::find_words, I think you're suggesting that one could use the same algorithm on a type S as long as S has a way to represent itself as a &str (or String)? So we would "map" the type S to it's &str-representation, find a split point in that representation and then have a function which maps the &str and an usize back to a S?
I can see how that would be useful when your have more complex things which you want to split. Even splitting console text with embedded ANSI escape characters should be easier with such a system.
In my case, I’m working with tuples of a string and a style annotation, namely genpdf::style::StyledString or genpdf::style::StyledStr. A paragraph is a sequence of styled strings, so I have to know which style to apply to which fragment. It is possible to use parts of the current API with these types, but it requires some code duplication and is not really clean.
(text_style provides a more general version of these types that can also be used for ANSI escape codes. Or a user could of course write their own abstractions that work directly on a string with escape codes, though that might be more complicated.)
I’ll prepare a draft and then we can discuss the details.
textwrap::wrap_algorithm
already works with theFragment
trait. What do you think about making thetextwrap::word_separators
andtextwrap::word_splitters
modules generic?As far as I see, it would not even be necessary to introduce a new trait.
word_separators::WordSeparator::find_words
could acceptS: AsRef<str>
instead of&str
and a function that creates a fragment fromS
and two indices.word_splitters::split_words
could acceptW: AsRef<str>
and a function that splitsW
at a given point with or without penalty and hyphen. (There might be some lifetime issues, but I think that should be solvable.)If you agree on the concept, I can prepare a draft implementation.
The text was updated successfully, but these errors were encountered: