Markupdown parser doesn't parse consistently
-
Continuing the discussion from -NaN% posters re-un-de-restuffed!:
Good point.
<br/>
<small>Filed under: [Nothing to see here, move along][1], [Found another fscking bug while posting this][1], [@discoursebot][1]
[1]: http://#So posting this, wanted an extra newline or two before the HR.
Simply pressing return means Discourse ignores it, fine, that's nothing I've not seen before, so I go for HTML and use a <br/> tag.
Before completing the tag, this happens:
WHAT?!
-
@loopback0 - Days Since Last Discourse Bug: 0
-
You forgot to close the br tag
When you don't properly close html tags some DOM implementation/parser will try to correct your mistake. and attempt to produce some meanigful output.lower you expectations when you provide invalid tags/syntax.
-
-
nope. only works in preview.
-
The screenshot was while typing it. It's fine once I closed it, but how the
fuckflip does a broken <br/> tag combined with the markdown for <hr> equal "I would like my text bigger please"?
-
well basically the "--------" tell the parser to take the line above it and insert between a
<h2>line_above</h2>so when the parser does that you get
<h2><br<h2> some text afterDue to the invalid markup. It tries to correct the unclosed h2 tag
and consequently closes( the H2) at the end/rest of the parsed block.<h2> <br <h2> some text afterand that is why you get the following text in header like so.
**any invalid markdown can mess the parsing and not just
<br
-
well basically the "--------" tell the parser to take the line above it and insert between a <h2>line_above</h2>
so when the parser does that you get
<h2><br<h2> some text after
That explanation makes sense, but IMO "-----------" should not mean <h2> or <hr> depending on whether there's a newline before it or not - it should mean the same thing consistently. I'm not sure where the blame for this lies but it's bonkers.
-
-
...Because having non-ambiguous syntax is not a requirement of making a markup language.
-
Ambiguity As a Feature™
(this is literally what Gruber said to me in multiple mails. Not having any idea what will come out when you type.. is a feature. He also non-ironically compared himself to.. well, you can read it)
You have created something great -- something with a life of its own. Why not let it grow naturally, and enjoy watching that as you'd enjoy watching a child grow?
It’s an exaggeration in terms of artistic ownership and expression (and quality), but to draw an analogy, to me this is like someone having written to Salinger asking for permission to write the continuing tales of Holden Caulfield and the Glass family.
-
Not having any idea what will come out when you type.. is a feature.
And you used it anyway?
Is ambiguity planned to be resolved inStandardCommonMarkDown?
-
Here's a markup language with no ambiguity:
for any input file, the output file is emptyAs an added bonus, the output will contain 100% fewer typos than the input!
-
A loser excuse:
"I didn't win the race, matter of fact I finished last. But what's important is that I at least tried."
if your ambiguity result in Chaos you just finished the race ... last.
-
Deterministic parsers are so 20th century.
-
He also non-ironically compared himself to..
I think he covered it with "It’s an exaggeration in terms of artistic ownership and expression (and quality)," but from the provided quote, I can't tell if he thought it was a good idea to ask permission, if the author should have just gone ahead and done it, or if no one should even contemplate it.
Based on outside context I guess it's the last option.
TRWTF is that the preview and baked posts sometimes come out different. I can understand the ambiguities among different implementations that you might find in various corners of the net, and for unintuitive line break rules, but to have ambiguity in the same application is nuts.
Daring Fireball: Markdown Syntax Documentation
