Missing parentheses after link
-
Input:
[foo](http://example.org/)(foo) [bar](http://example.org/)(bar )
Expected:
Actual:
-
Looks like another version of the bug reported here:
http://what.thedailywtf.com/t/formatting-bugs-with-intervals-and-hyperlinks/992
-
-
Protip, as @ben_lubar noted, you really want to look at Babelmark when testing Markdown quirks. The language (and I use that term loosely) does not really have an unambiguous spec. It is something that John MacFarlane is working on currently @sam so you should just email him if you want it to happen faster. No reason to do anything other than that at this time.
-
I am really not following... babelmark is showing that our markdown parser is failing... as an added bonus its not even in the list of markdown parsers there.
marked works and pagedown works.
its clearly just another bug in our markdown parser. https://github.com/evilstreak/markdown-js and to be honest the code in there makes me want to cry:
To say: https://github.com/chjj/marked/blob/master/lib/marked.js#L448
What code base would you prefer hacking on?
-
I don't think that's a battle we need to fight right now. If you want maximum benefit from your actions, work with John MacFarlane on the official Markdown Next spec. That is the best course of action versus Yet Another Parser That Interprets an Ambiguous Spec a Certain way.
Fix the fucking spec.
Otherwise, there are other things we need to do.
-
No less true of Markdown than anything else.
-
I hereby appoint pandoc as the Interim Markdown Spec.
There, now we have a speclementation.
-
Markdown does not even have a proper spec and by proper I mean one that can be implemented without ambiguity. Turns out, John Gruber is... kind of a shitty computer scientist, which may come as a surprise to no one.
So in this case there is no standard, just differing interpretations of an inherently ambiguous spec.
-
In which case every interpretation of the specification is by definition its own standard.
-
Problem is Pandoc throws in a bunch of extra crap that's not even related to Markdown, hence "pan" as in "opening Pandora's box".
-
I don't much care for a spec or whatever, what I care about is
- A usable editor that does not confuse the bejesus out of people
- Code that I can hack on and amend to fix my pet problems without wanting to rip my eyeballs out.
I guess you can argue this is a huge edge case or whatever. But.... what terrifies me is that I have little chance of fixing this issue without wanting to kill myself.
-
If you care about actually fixing the problem correctly, you should care about the spec. Not having a proper spec is what gets us into these PHP-esque messes.
-
How is a spec going to help me decipher what the fuck this does:
var origMatcher = /^!\[(.*?)\][ \t]*\([ \t]*([^")]*?)(?:[ \t]+(["'])(.*?)\3)?[ \t]*\)/; m = text.match(new RegExp("^!\\[(.*?)][ \\t]*\\((" + urlRegexp + ")\\)([ \\t])*([\"'].*[\"'])?")) || text.match(origMatcher); if (m && m[2].indexOf(")]") !== -1) { m = text.match(origMatcher); } if ( m ) { if ( m[2] && m[2][0] === "<" && m[2][m[2].length-1] === ">" ) m[2] = m[2].substring( 1, m[2].length - 1 ); m[2] = this.dialect.inline.__call__.call( this, m[2], /\\/ )[0]; var attrs = { alt: m[1], href: m[2] || "" }; if ( m[4] !== undefined) attrs.title = m[4]; return [ m[0].length, [ "img", attrs ] ]; } // ![Alt text][id] m = text.match( /^!\[(.*?)\][ \t]*\[(.*?)\]/ ); if ( m ) { // We can't check if the reference is known here as it likely wont be // found till after. Check it in md tree->hmtl tree conversion return [ m[0].length, [ "img_ref", { alt: m[1], ref: m[2].toLowerCase(), original: m[0] } ] ]; } // Just consume the '![' return [ 2, "![" ]; },
m ? ... m.dialect.inline.call_.call ? I am just too stupid to be able to understand a lot of this.
-
Code sanity is a different issue though. Without a real, non-ambiguous spec you are always building on sand with Markdown.
-
-
>```javascript
// found till after. Check it in md tree->hmtl tree conversionWe're using Hypermext Tarkup Language? Web 3.0, baby!
-
So that's why you picked Markdown as opposed to bbcode, right?
You're bitching about a problem that you could solve. Fucking man up and solve it by writing a spec that's unambiguous.
It hasn't stopped bbcode's many proliferations.
-
As I have said repeatedly, that is what John MacFarlane is working on right now. It takes the time it takes.
-
So that's why you picked Markdown as opposed to bbcode, right?
You're bitching about a problem that you could solve.
By not using markdown? amiright?
-
I really don't understand why Markdown uses * for italic and ** for bold, when the convention has been practically forever to use * for bold and / for italic (and _ for underline).
-
I really don't understand why Markdown uses * for italic and ** for bold, when the convention has been practically forever to use * for bold and / for italic (and _ for underline).
Becuase it was created by a madman.
-
-
Except that wasn't the solution I was proposing.
Nobody seems to complain that each forum software has its own interpretation of bbcode. Provided the very simplest stuff is consistent, no-one will complain if you have different Markdown for the most complex stuff mostly because almost no-one will use it anyway (lack of discoverability, lack of need etc.)
The fact you have three separate routes for content entry which are clearly conflicting with each other is also really not helping your case.
If you don't like the Markdown spec, don't use it. Write your own. You're already determined to reinvent the forum as we know it, why not go one step further and reinvent Markdown?
Or drop Markdown and use bbcode. Trying to be all things to all people is a headache you've made for yourself.