fix(block): headings terminate at the end of the line

[petebacondarwin]

No description provided.

[petebacondarwin]

@inca is it possible to merge my PRs and get a new release out?

[inca]

Hello,

I am sorry, I cannot accept this PR. It's not a fix, it's a breaking syntax change, which also goes against a simple rule that blocks are separated by at least one blank line.

[petebacondarwin]

Hi - where is that rule defined?
Every markdown renderer that I have tried stops the heading at the end of the line.

Try adding

# this is a header
This is some paragraph

into http://daringfireball.net/projects/markdown/dingus

Or even into a github comment:

this is a header

This is some paragraph

In Rho, you end up with something that looks like

this is a header
This is some paragraph

[inca]

The rule is right here: https://github.com/inca/rho/blob/master/SYNTAX.md#basic-concepts — and it was there since the beginning.

Remember, Rho is not a "markdown on steroids". It was never advertised as such. It does not pass Markdown test spec b/c it has a stricter rule set (e.g. no variations on ul markers, structural indentations, etc.).

P.S. All other PRs are merged and released.

[petebacondarwin]

Oh, I see. That makes me sad. Since I have a whole load of markdown that I want to render, which does not follow that rule :-(

Thanks for merging the other PRs :-)

[inca]

I am sorry for that, really.

As part of the excuse, I'd like to explain why this rule was introduced in a first place. Rho emerged as an open source part behind an educational platform where lots of non-tech people were forced to drop their wysiwyg habits of authoring their courses in MS Word and start thinking in terms of a limited semantic vocabulary. When we explained the concept of "block" to them, it became apparent that all block types must follow the same rule (one blank line delimiter). Exceptions to this rule would only spoil the overall understandability, especially combined with selectors and nested constructs (like ul > li > h3). In general the conclusion was made that stricter rules == better user experience in a long run. You can think of it as of what ESLint does for modern JavaScript — only applied to semantic texts.

One side benefit of this rule applied to headings is that they naturally begin to stand out in plain text (a blank line after a heading makes it clearly visible and thus better perceived as a structural entity). This is something that is very difficult to achieve in Markdown just because there is no language rule to enforce that.

[petebacondarwin]

I accept this explanation, and I appreciate that it is good for your authors.
I will keep a fork of this project, which contains this "fix" for our purposes.