So, to spam my own thread...
This turns out to be a little trickier than one might think. I mean, I can pretty easily support it in the 'dumb' way that BitmapText does ('dumb' not casting aspersions in this case just saying that there are almost no 'smarts' involved in the logic) but I feel like it might not be what most users would want when they think about word wrapping.
The tricky part is how wrapping interacts with the auto layout.
BitmapText does word wrapping in a very simple way. If you specify a 'box' for the text then it will wrap to try to stay in that box... potentially pushing out the bottom.
Lemur lays out GUI elements by first asking them their preferred size. In the case of BitmapText, this preferred size would be without word wrap because it is specifically bypassed in order to get a proper size. Thus one long string will just appear to the layout code as a really wide component.
Now, the layout may then smack it back down to a reasonable size and then word wrapping could wrap... but then the layout didn't have a chance to know about the new vertical size and thus things might be squished with other GUI elements.
The use case that can sort of be handled is where the developer has specified a specific size for some outer component and there are few other children to compete with. Otherwise, if there are lots of other children then the layout could still be strange.
So, when in doubt, I do what I always do and remind myself what Swing does in this particular case. Swing doesn't. At all. I always thought that was sort of strange but a) never encountered a use-case when I needed it, and b) hadn't thought through the implications I've just discovered above. They have a completely separate GUI element if you want to have wrapped text in a 'label' style component (JTextArea).
Now, things like edit panels could have some notion of a "width" that is separate from their layout size. I think any proper wrapping policy would have to incorporate a concept of 'text width' to play nice with layouts. Lemur's multiline edit support doesn't have this yet but presumably it could if the issues are solved.
With all of that, I'm really tempted to create a separate 'wrapped text model' concept and have a separate text GUI element for when you want something like a Label but with word wrapping support. Incorporating word wrapping into all of the Label-based GUI elements will be problematic, I think. Furthermore, I think it makes less sense for Buttons and other classic Label use-cases.
In this spit-balled design, I'd add a TextWrapPolicy class that could split text based on customized split patterns. (Maybe you want to split on only some kinds of white space or characters or whatever.) I'd add support for TextWrapPolicy to DocumentModel (which would need it for navigation anyway). I'd also perhaps create something similar to Swing's JTextArea for displaying read-only text with word wrap (or just make TextField support read-only views or something).
These GUI elements would internally keep two versions of the string. One that is the original and one that has been wrap-split and recomposed with line feeds in it (the existing GUI elements already support multiline text with line feeds.) Then these new GUI elements would just use the existing internal TextComponent with the recomposed text.
Would having to use a separate TextArea type of GUI element meet your use cases?
I really am curious because I will meet this issue in my own game in the next month or so and the above would work for me... because the word-wrapped fields are very specific (description text, etc.) and can be trivially bound by some logical text width. I just don't know if it meets all cases.