fix: render of &str and String doesn't respect area.width

[thscharler]

Those two shouldn't write outside the given area I would think.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 94.3%. Comparing base (d370aa7) to head (f8e5b6c).

Additional details and impacted files

@@          Coverage Diff          @@
##            main   #1177   +/-   ##
=====================================
  Coverage   94.3%   94.3%           
=====================================
  Files         60      60           
  Lines      14677   14679    +2     
=====================================
+ Hits       13841   13843    +2     
  Misses       836     836           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[matta]

Personally, I'm not a big fan of str implementing Widget. There are many ways to interpret the intent, and it isn't clear what it'll actually do. Because of the way traits show up in rust docs, I'm not sure how to document the behavior.

Should a str Widget behave like a Span with no styling? Or a multi-line thing? What if the Str has newlines? Should the rendering word wrap within the area? It would be good to document the answer.

If a str Widget is basically a Span with no styling it would be nice to find a way to share more of this implementation with Span. See @joshka 's commit yesterday which fixes rendering zero-width characters -> d370aa7. Does that bug apply to Str widgets too? If this is a case it might be better to remove the str Widget impl and instead have an UnstyledSpan widget. People can then write draw(UnstyledSpan(my_str)) if they want to.

[thscharler]

Personally, I'm not a big fan of str implementing Widget. There are many ways to interpret the intent, and it isn't clear what it'll actually do. Because of the way traits show up in rust docs, I'm not sure how to document the behavior.

Should a str Widget behave like a Span with no styling? Or a multi-line thing? What if the Str has newlines? Should the rendering word wrap within the area? It would be good to document the answer.

I stumbled upon this implementation, and just tried it. Personally I wouldn't have expected it to handle newlines in any way and form.

But I agree that the behaviour should be documented.

If a str Widget is basically a Span with no styling it would be nice to find a way to share more of this implementation with Span. See @joshka 's commit yesterday which fixes rendering zero-width characters -> d370aa7. Does that bug apply to Str widgets too? If this is a case it might be better to remove the str Widget impl and instead have an UnstyledSpan widget. People can then write draw(UnstyledSpan(my_str)) if they want to.

Probably Buffer::set_string_n() should use the same algorithm as Span.

I looked at that one and wondered why graphemes(true) doesn't handle that case. As far as I understand http://www.unicode.org/reports/tr29/#Extend it shouldn't break at those zero width joiners. Or was it just a case of invalid data?

[orhun]

This LGTM, don't see reason why we shouldn't have it.