Newline/line-break handling

[tmedwards]

What are everyone's thoughts on removing most line-break processing? In other words, instead of having to use line continuations or one of the no-break features, the default would be to not convert most newlines into line-breaks in the first place.

What I'm currently imagining is:

1. Single newlines are not altered.
2. Two or more consecutive newlines are turned into a double line-break or denote a paragraph—hopefully you get the idea.

For example, the following text:

She's a pretty,
pretty pony.


Fnord.

Currently transforms into the following in SCv2:

She's a pretty,<br>
pretty pony.<br>
<br>
<br>
Fnord.

What I'm thinking about for SCv3 is:

She's a pretty,
pretty pony.
<br><br>
Fnord.

Or, ideally (but don't count these chickens):

<p>She's a pretty,
pretty pony.</p>
<p>Fnord.</p>

---

SEE: Issue #18 for prior discussion on whitespace handling.

[holly-hacker]

I just started playing around with SugarCube 2 and found the current line break behavior very weird, being used to HTML and Markdown. I currently have to configure my editor to turn on line wrapping to be able to write longer paragraphs which feels wrong. Ideally I'd see the same behavior as Markdown where a single line break is ignored and multiple consecutive line breaks creates a new <p>. It may be useful to see 2 line breaks as the start of a new <p> and any extra line breaks turn into <br>.

As an example:

This is some text.
I like this text.

This is a new paragraph.


This is another paragraph, but with more spacing.

Would translate to:

<p> This is some text. I like this text. </p>
<p> This is a new paragraph. </p>
<br>
<p> This is another paragraph, but with more spacing. </p>

[greyelf]

the default would be to not convert most newlines into line-breaks
Does that mean there would be a configuration setting that would allow the Author to chose the current method if they wanted it?

Personally I like the idea of suppress the auto-conversion of single line line-breaks, and while the <p> element based outcome would likely be best for a CSS styling point-of-view, only converting multiple lines of consecutive line-break into <br> elements would be better than the current method,

note; I don't agree producing an outcome that mixes <p> and <br> elements, as that makes using CSS to re-style the page based on current ViewPort dimensions harder.

[tmedwards]

Does that mean there would be a configuration setting that would allow the Author to chose the current method if they wanted it?

If by current style you mean the v1/v2 behavior, then no.

The v3 behavior will be a clean break, moving the action to the renderer where it's always belonged.

[greyelf]

cool. Less foot-guns.

[tmedwards]

Verily.