The neverending story of screen lines and text lines in text widgets
continues... Since scrolling (and "scanning") is done in terms of text
lines, it is impossible to view the last portion of a paragraph (a
contiguous sequence of characters without a line delimiter), if that
paragraph should occupy more screen lines than the widget is able to
display at a time.

I can see that doing everything in terms of screen lines requires a
little bit more work, but it would be nice to have it, wouldn't it?

--Juergen

|> The neverending story of screen lines and text lines in text widgets
|> continues... Since scrolling (and "scanning") is done in terms of text
|> lines, it is impossible to view the last portion of a paragraph (a
|> contiguous sequence of characters without a line delimiter), if that
|> paragraph should occupy more screen lines than the widget is able to
|> display at a time.
|>
|> I can see that doing everything in terms of screen lines requires a
|> little bit more work, but it would be nice to have it, wouldn't it?
|>
|> --Juergen

Yep.  It's on my list of things to do.  When I first implemented text
I didn't foresee people having text lines that were actually paragraphs
and spanned many (e.g. >> 2) screen lines.

Many word processing programs use this style, in which the newline
character indicates a paragraph break and the word processing program is
expected to do the filling and justification: with the increasing
popularity of tools like FrameMaker, you're seeing more of this on Unix as
well.  We're seeing increasing culture clashes as people with that kind of
background post their articles to Usenet, but it is a reasonable thing to
do, I think, so it should be handled.

--