Skip to content
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

Generic word separators and splitters #401

Open
robinkrahl opened this issue Jun 29, 2021 · 2 comments
Open

Generic word separators and splitters #401

robinkrahl opened this issue Jun 29, 2021 · 2 comments

Comments

@robinkrahl
Copy link
Contributor

robinkrahl commented Jun 29, 2021

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.

@mgeisler
Copy link
Owner

Oh, that's interesting!

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.

I would love to see what you can come up with.

@robinkrahl
Copy link
Contributor Author

robinkrahl commented Jun 30, 2021

Yes, that is mostly what I had in mind.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants