I like it, as it lets me format at 80-char breaks to prevent infinite line lengths for paragraphs of text. This makes Github diffs easier to read as well.

except when you add one word and re-flow the entire paragraph

That's when semantic line-breaking comes into a picture. Put a line break before each new sentence and before each clause in a sentence. That makes the text much more diff-friendly, and tends to keep the line lengths at bay too.

Your editor should be able to help with that. For example in vim: `gqap` will reflow the current paragraph, or while in visual select mode you can use `gq` to reflow your selection).

that's exactly what causes the viewing diff problem that I was replying to

--word-diff=color is your friend in this case.

This still ruins the diff view of the code, though. (e.g. git blame)

I think you can achieve that with 2 spaces at the end

Yes, but, my gripe is how markdown breaks standard plain text behavior, without requiring extra formatting (those two spaces). They should have required the extra formatting for the opposite case, if you want to break a line in your code for some reason but not in the final result. Confusingly those two spaces also don't work in hacker news comments while some other markdown features do.

If it was like plain text, with a few ascii symbols used for formatting (like *, _, ...), it'd have been more fantastic than now.

BBCode is better imho.

> while some other markdown features do.

The only two markdown features afaik that work on HN are italics with asterisks and code blocks with 4 spaces.

That's it.

The backslash\ may qualify, and it’s part of the standard.

> 2 spaces at the end

I prefer just plain "<br/>" because it does not mess with my editor configuration, which otherwise I have to constantly tweak between "strip all whitespace at the end of line" and back.