A new line should continue the same paragraph (original Markdown behaviour)
A new line should create a literal line break (<br> in HTML)
A third option has not been widely discussed on this forum (as far as I am aware):
A new line should start a new paragraph.
Roses are red
Violets are blue
Would produce:
<p>Roses are red</p>
<p>Violets are blue</p>
Which may well be what the writer is expecting. Or not.
Pros:
It may be the writer’s intent for a new line to create a new paragraph.
New lines do start new paragraphs in many texts (but are usually indented).
It does not produce a bunch of break tags that lack semantic meaning.
The behaviour is similar to Microsoft Word, the most widely used word processor in the world.
If users causally enter line breaks, at least semantic paragraphs would be generated (intentional or not).
Cons:
It may not be the writer’s intent for a new line to create a new paragraph.
As with literal line breaks, many existing Markdown documents would break.
It does not provide a solution for people who like to hard wrap their text.
It is not helpful for song lyrics or other text that requires literal line breaks.
If the final line of a paragraph covers the width of the text editor it is hard to see that a new paragraph starts on the next line. The double new line requirement for new paragraphs thus improves readability.
Although I’m not favour of the change, I thought it would be worth discussing this third option.
And thus it might be a good idea to provide override in the document declaration. e.g. Line_Break: On
!CommonMark: 0.1.23-github.username.projectname
Title: Title for the top bar of any browser
Date: 32-4-2002
Line_Break: On
# First Header #
A document
With linebreak because the user wants
to...
Would let people use it when needed (or perhaps always in user’s settings)
For prose it’s usually desirable to allow source text to contain newlines while the resulting rendered content fluidly adpats to its container or whatever styles are applied to it. This is particularly important once you consider the growing diversity of screen sizes used to consume content.
We can’t compare writing in a markup language with writing in a WYSIWYG environment. Of course in Word pressing the Enter key results in a new line, but when we’re manipulating the source “code” for text, WYSIWYG features like this would muddle the waters and make the outcome less predictable overall.
For that reason, IMO not even the line breaks should be considered for a (default) feature – but perhaps we can envision a mode that can be activated within a block (like HTML’s <pre>formatted text). Even then, line breaks using backslashes are so easy to produce that I don’t think such a block would be warranted (in the base spec, that is).
That line block syntax was suggested in the Spoiler topic. For paragraphs there is no need to use line blocks though; just use a double new line (although a line block could contain a mix of new paragraphs and line breaks).
A paragraph is one or more lines of text followed by one or more blank line. Newlines are treated as spaces, so you can reflow your paragraphs as you like. If you need a hard line break, put two or more spaces at the end of a line.
So (not quite correct but transports the point that all variants are possible):
\n\n becomes </p>\n<p>
<space><space>\n becomes <br/>\n
\n becomes .
@waldyrious In MS Word Return actually produces a paragraph; Shift+Return produces a line break. But your conclusion still holds true; the default of a text editor is usually to insert a line ending when enter is pressed. While different across software categories this is both quite consistent within them, so it is probably best not to fight it.
Extending your example of using line breaks in source text, I even indent non-sentence-starting lines like this:
Most documents go through several versions
(always more than you expected)
before they are finally finished.
Accordingly,
you should do whatever possible
to make the job of changing them easy.
First, when you do the purely mechanical operations of typing,
type so subsequent editing will be easy.
Start each sentence on a new line.
Make lines short, and
break lines at natural places,
such as after commas and semicolons,
rather than randomly.
Since most people change documents by rewriting phrases and
adding,
deleting and
rearranging sentences,
these precautions simplify any editing you have to do later.
This helps with finding the right sentence to edit when working with comments made on paper or a PDF: Skim from the comment backwards to the beginning of the sentence, match the unindented words to the beginning of the sentence. Also this feels even more pythonic because conjunctions never appear at the beginning of lines, helps with keeping the sentence-starts diverse and resembles markdown-style bullet lists.
A text-IDE might detect sentence parts and format them automatically as code formatters do for program source code. In that case I would expect the indent to be inserted upon pressing return after a semicolon for example, like an IDE would do after an opening curly bracket.
Yes, that’s what I meant, sorry for the ambiguity. I was talking about the visual effect (in the final document) of pressing the enter key, whereas (regardless of using the Shift key in combination) the current line is interrupted. I edited my post to change “newline” to “new line”, to reduce the potential for confusion.
That’s a great idea, I will start using that as well and will probably implement it in my semantic-linebreaker
