I’ve found a case where the default line-break functionality isn’t sufficient. According to the spec (@ http://spec.commonmark.org/0.12/#hard-line-breaks), in order to generate a line break (<br />), you need to either:
add two spaces followed by a line ending character, -OR-
enter a backslash + line ending character.
There are legitimate cases where one would need to generate line breaks IN-LINE without the need to enter a line ending character. Given a token, say somelthing like \^, the following text:
No, those two code snippets would render the same obviously.
Suppose you have a site that supports localization of n number of languages languages. The localization key/value pair strings are stored in files where typically one line is one record:
resources.en-us.json file:
{
key1: "english one",
key2: "english two"
}
resources.es-la.json file:
{
key1: "español uno",
key2: "español dos"
}
Now suppose I want the flexibility to specify line breaks on the UI in between the language and the word that follows - without the need of manually marking that up in html. I would like to maintain the consistency of the resource file format of one-line-per-record and explicitly specify the line break in-line, rather than implicitly inferring when encountering [2 space + line ending] or [backslash + line ending]. The resource key/value might look like:
key1: "english\^one",
etc… Retrieving that resource string and passing it through the Commonmark parser would result in:
This use case doesn’t seem to be compelling enough to justify adding another bit of syntactic complexity. After all, if you’re running the CommonMark parser on strings you extract from a json structure, you could just as easily do your own preprocessing, converting \^ to <br />, for example, before running the parser on it. Or you can just insert a raw <br />. This is perfectly valid CommonMark: abc<br />def.
