feat(line): add Line::raw constructor

[orhun]

closes #508

[orhun]

Question: should we break newlines into different spans? e.g. test\ntest will result in vec![Span, Span] etc.

[codecov]

Codecov Report

Merging #511 (9d4db84) into main (0c7d547) will increase coverage by 0.13%.
Report is 8 commits behind head on main.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main     #511      +/-   ##
==========================================
+ Coverage   89.93%   90.06%   +0.13%     
==========================================
  Files          41       40       -1     
  Lines       11334    11267      -67     
==========================================
- Hits        10193    10148      -45     
+ Misses       1141     1119      -22     

Files Changed	Coverage Δ
src/text/line.rs	96.75% <100.00%> (+0.20%)	⬆️

... and 9 files with indirect coverage changes

[joshka]

There are a few ways we could handle newlines in Line:

1. reject them completely (panic and consider adding some try_ methods)
2. remove them during creation and create a single Span that has a single Cow::Owned constructed from the input with the lines removed.
3. remove them and create multiple Spans that each hold Cow::Borrowed slices.
4. ignore them and handle it on render (I don't like this approach as it means every thing that takes Line now has to understand that it might have newlines).

Option 3 makes most sense to me, but Option 1 is also possible. Option 2 allocates new memory, but is probably a reasonable approach and "performant enough" except for massive strings. Option 4 is a pretty terrible one.

[kdheepak]

I think I have some naming + semantic questions about what we want Line to be?

From Wiki

In computing, a line is a unit of organization for text files. A line consists of a sequence of zero or more characters, usually displayed within a single horizontal sequence.
The term comes directly from physical printing, where a line of text is a horizontal row of characters.

Line currently uses Vec<Spans> as the implementation. But it is only during rendering that we decide where the "end of a line" should be. Right? If someone wants to store this content in a Paragraph:

This is a sentence that
wraps to the next line.
This is another sentence that doesn't wrap to the next line

Do they make 3 lines to convert them to a Text object?
Do they make 2 lines with the first line having a \n in it? Should the first line split it into 2 spans? What if they want This to be bold but the rest not? Then the first line would have 3 Spans because Span is the lowest unit of styling.

[orhun]

I think @joshka's 3rd option makes the most sense. If everyone agrees then I can update the PR.

[joshka]

Line currently uses Vec<Spans> as the implementation. But it is only during rendering that we decide where the "end of a line" should be. Right? If someone wants to store this content in a Paragraph:

I think it's reasonable that Line would have a fn wrapped(params) -> impl Iterator<Type = Line<'a>> method that helps make the distinction more obvious.

Do they make 3 lines to convert them to a Text object?
Do they make 2 lines with the first line having a \n in it? Should the first line split it into 2 spans? What if they want This to be bold but the rest not? Then the first line would have 3 Spans because Span is the lowest unit of styling.

3 lines Text::raw(content: T: Into<Cow<'a, str>>) method will handle Text::raw("Line1\nLine2\nLine3") by creating 3 lines each with a single span:
https://github.com/ratatui-org/ratatui/blob/5498a889ae8bd4ccb51b04d3a848dd2f58935906/src/text/text.rs#L45-L57

So at the least for consistency, Line should ever have a newline character. This also avoids having every widget that takes a line parameter have to work manually handle it (e.g. what should buffer.cell_mut().symbol = "\n" do? I'm sure there are other arguments as well.

[joshka]

Please add newline handling ("a\nb" becomes Line::from(vec![Span::raw("a"), Span::raw("b")]))

[orhun]

Updated in 9d4db84