Introduce LineEnding to editor and fix inconsistencies

[hecrj]

Fixes #2730.

[CyberCeisc]

These changes still leave us with conditions where the control/content-store is changing the content in unexpected/unintuitive ways.

If I initialise the content with text_editor::Content::with_text("Line 1\n") the value returned from .text() is "Line 1" as the control has removed the ending newline from the content.

Given that trailing newlines in files have importance in various circumstances, I would not expect the control to be making changes to the provided content.

For the above example, I would expect the initialised control to have content which is two lines long, but it does not do so.

If it is initialised with content which has a mix of CR/CRLF/LF, the character inserted on pressing return/enter is dependent on the line-ending it has determined for the line you were on at the time you pressed return/enter, which results in the same action (pressing return) having multiple different possible outcomes.

It can also make changes in places unrelated to where the cursor is currently placed. If I start with content of "Line 1\nLine 2\r\nLine 3", text() returns "Line 1\nLine 2\r\nLine 3" as expected. If I then go to the end of "Line 1" in the editor and press delete, I get "Line 1Line 2\nLine 3", which has removed not only the '\n' (expected behaviour) from where the cursor is but also the '\r' from what was the end of line 2 (unexpected). Pressing return then results in "Line 1\nLine 2\nLine3" which is different content than I started with despite me expecting to have simply deleted and replaced a single new-line character. The actions which are being passed through to the update method when doing this are simply Edit(Delete) and Edit(Enter) and give no indication that content located anywhere but where the cursor is located is going to be changed.

There also doesn't seem to be a way of specifying which new-line character to use with the editor, so an editor with empty content from ``text_editor::Content::new()will use\n` regardless of whether this is the correct choice for the user at this stage.

text_editor::Content::selection() also ignores differing line endings and concatenates selections spanning multiple lines with only \n, even when initially provided content which consistently uses \r\n for line endings. As such, it's not possible to ensure the value returned in the selection represents the underlying data or what might be written out to a file if the content were to be saved.

I would question why this has been implemented with the content stored as a collection of lines. For display purposes it could be considered as a range of lines, but in terms of the actual underlying content, especially if loaded from a file, it's just a collection of bytes some of which have specific/special meaning when being displayed.

[hecrj]

@CyberCeisc These are all cosmic-text limitations.

We will have to wait until line endings are properly handled there, or roll our own editing logic.

[CyberCeisc]

@CyberCeisc These are all cosmic-text limitations.

We will have to wait until line endings are properly handled there, or roll our own editing logic.

In which case can we re-open the issue I raised to show that it has not been fixed as it feels likely I won't be the only one who the current behaviours create problems for?

[hecrj]

Open a new one. The original issue is fixed.

\n is not appended unconditionally anymore. The editor always returns the visual text. Line endings at the end can be re-appended with Content::line_ending—as I did in this PR in the editor example.