> 5. A semantic line break SHOULD occur after an independent clause as punctuated by a comma (,), semicolon (;), colon (:), or em dash (—).

Uh oh, that’s incompatible with standard em dash usage, which is with no surrounding whitespace.

(I’m designing a lightweight markup language of my own, and it’s tempting to special-case an em dash at the end of a line that is not preceded by a space, to join to the next line without inserting a space, but I’ve been trying to avoid nuance in rules. But I definitely do want to put line breaks after em dashes sometimes.)

According to Wikipedia: "Dashes have been cited as being treated differently in the US and the UK, with the former preferring the use of an em dash with no additional spacing and the latter preferring a spaced en dash."

Though I prefer the spaced en dash myself, and I am in the UK, I think there's probably a lot of variation on both sides of the Atlantic.

If you are using Markdown you can use an HTML comment—<!--

-->like this. I'm okay with that because there are some edge cases [1] in CommonMark that I absolutely need to use one anyway.

[1] https://talk.commonmark.org/t/foo-works-but-foo-fails/2528

A hairline space between em-dashes can be quite visually pleasing (in American writing; British uses full spaces around en-dashes). Like what Medium does.

But in that case I would prefer that the source text still has no spaces. Such things can be added in postprocessing.

Useless info but in LaTeX, you could write %\n instead of \n to prevent the surrounding whitespace.

Came here to say this too. Huge fan of semantic line breaks, both for VCS and for the eyes (makes it easier to parse the structure of a document)

Looks good - but I do not agree with

> 3. A semantic line break SHOULD NOT alter the intended meaning of the text.

That should be #1 MUST NOT

SemBr author here. I chose SHOULD NOT for this rule for a couple reasons: First, as an affordance for text with ambiguous or unknown meaning. Second, as a hedge against introducing new meaning unintentionally.

Adding a semantic line break inherently changes the relationship between words, and we can't always be sure about the intended meaning of text. If this were MUST NOT, then any modification would risk violating the spec.

Then again, this may be my own, idiosyncratic reading of RFC 2119. If you'd like to discuss this further, feel free to open an issue on the GitHub repo here: https://github.com/sembr/specification/issues