|
|
|
|
|
|
by DemocracyFTW2
1225 days ago
|
|
|
> Asciidoc fixes this elegantly. Instead of making trailing spaces indicative of a significant break, they make a trailing + character indicate the break. This solves basically every single problem the Markdown implementation has. You can visually scan for the + at the end of a line, you can have syntax formatting that makes it significant, and, going the other way, you don't need special editor features to show you its presence. That's not an elegant solution, this is a stray markup disaster waiting to happen, and in both directions: re-wrap a paragraph (I'm doing it all the freaking time), edit some more so you can't just ctrl-z, and now you've got those plus signs sprinkled throughout your text mixed with non-special plus-signs. Manual line breaks are too infrequently used to warrant such an unconspicuous markup with such a frequently used character IMHO. It's also totally arbitrary and not backed by widespread precedent. Just use <br> for heavens' sake, you can at any time just copy-paste it to reduce the chore, its semantics are among the most published text markup conventions ever, and it's in most situations unique enough to be safely searched-replaced in a document without all the headscratching that /\+(?=\n)/ vs /\+(?!\n)/ entails. Plus, <br> is impervious to reflowing paragraphs. What's not to like? |
|
|
Trailing + for breaks is for one-offs exceptions, usually with semantic reasons. If you are manually flowing a paragraph for some reason (mostly, that’s an antipattern, but...), rather than indicating a single special break, where “rewrapping” is a thing that makes sense, then using the [%hardbreaks] directive on the paragraph makes sense; there's also a document-level toggle in the header if you want to do this for a whole document. (And many of the contexts where you'd want hard breaks have their own block type, with other linked formatting changes: literal, listing, source, and verse blocks.)