Actually, this isn’t the motivation. We don’t parse inlines until we’ve divided text into blocks, so there is no reason in principle why we couldn’t allow setext headers to interrupt a paragraph. So this might be a good time to reconsider this issue.
OK, repharse a bit: it’s not arbitrary back-tracking, just one block. IOW, you can’t do a simple parse-block-then-parse-inlines, since the inlines can change if there’s a setext marker following the text. It’s of course doable, but I was relieved that there’s no need to do that…
Given that there isn’t complete uniformity here, a case might be made for moving commonmark into group 1, or group 3. What are people’s thoughts on this? Group 2 doesn’t seem a very useful behavior.
(A big “FWIW” around the following.)
IMO #2 makes most sense.
With #1, and especially when just one
- is needed it seems easy to end up with huge mistaken headers. (Plus, imagine an editor with highlights: if you want enter some
- foo bullet after some text you’ll see it flash as a header line; not a strong point, but I think that such flashes are signs of surprise text parsing which is problem.)
Option #3 seems less dangrous for that, but adds a result that looks even more broken.
With both of these it becomes impossible to use
---s to separate a block of text with rules without newlines (and that seems to me like a useful thing).
Maybe a good summary is that I think that the problem of breaking text where people expect #1/#3 is smaller IMO than breaking a #2 expectation.
# more suited for multiple-lines?)