Support for GitHub Flavored Markdown

[akzhan]

What about support of widely used GitHub Flavored Markdown?

We need it. This dialect known as the Redcarpet.

[ashb]

Support for this as a dialect should possible.

Its probably not that much work if you base it on the existing standard dialect (look for Maruku how do that).

Unfortunately I don't have time to do this right so 'patches welcome' I'm afraid.

[gjtorikian]

So I have actually already done this: https://github.com/gjtorikian/namp/blob/master/lib/markdown.js#L1143

But my repo is currently messed up because of some changes I made a month ago. I don't think it would be appropriate to do a PR but you can by all means just copy the dialect code.

[akzhan]

@gjtorikian, thanks a lot. I will rebase your commits to send PR.

[gjtorikian]

Also forgot to add that I also do not have the time to fix my own code at the moment--hence lack of PR ;p

[akzhan]

NP. Anyway some codebase is very good point to work on than from scratch.

[rlidwka]

+1

@akzhan, it is ready?

[akzhan]

@rlidwka, @1602 shows me another project at https://github.com/isaacs/github-flavored-markdown, and now it meets my needs.

[rlidwka]

@akzhan , oh... that's the same old Markdown engine originally written in Perl and ported line-by-line then.

Unfortunately, it has no central repository (forks are scattered all over the internet). It's written using regexp very much that's good in perl but hard to maintain in javascript. It has no plugin system, so everyone just naturally rewriting it's core to every specific project.

I think i'd stick with this one...

[ashb]

As you might have noticed I did a lot of tidying up (mainly getting the test suite running again) and closing of the easier bugs on the markdown project this weekend.

Hopefully I'll be getting onto this soon if someone else doesn't beat me too it.

[dpaola2]

I'm working on a super simple, open source Markdown editor in the browser (based on Mou). I'd absolutely love to have github flavored markdown, and basically would love to have this feature included in markdown.js.

Just voicing my support on this issue.

Thanks so much for your work, @ashb.

[mattly]

any news here? I'd love to have this as well.

[ashb]

I made a start on the gfm branch - Can't remember how far I've gotten though...

[jshirley]

I got really inspired by seeing the checkmark support in GFM (https://github.com/blog/1375-task-lists-in-gfm-issues-pulls-comments) and would like to see this adopted in.

However, when I started to poke at it it seems that is conflicts with the check for links [.*] vs [ ] and [x]. I'm not sure how best to solve this in a good way, but I got it working by simply doing a check in the link handler if the res[1] is ' ' or 'x'.

If you want to give some further guidance, I can try my hand at some other contribution.

And not to hijack, but I don't think GFM is feature complete without being able to update the checkmark content in some capacity. Is this something you think ultimately markdown-js should facilitate or should it be entirely up to the application?

[ashb]

Yay for ambiguous markdown syntax. Cos there's not enough of that already...

And not to hijack, but I don't think GFM is feature complete without being able to update the checkmark content in some capacity. Is this something you think ultimately markdown-js should facilitate or should it be entirely up to the application?

My first thought is that this is something application specific, but we might be able to help by giving functions to find the character offset to the [ ] so that it can be easily changed... Hmmm.

[jshirley]

Getting the character offset would be really useful, generating markup like would make this pretty easy to implement in any application. As it stands, I did a really terrible regex based on the remaining line so I can match.

I pushed my earlier attempt to http://j.shirley.im/tech/yui/gallery-markdown/ which shows it working with the horrible regex, just to demonstrate usage.

I plopped my hack in the Gruber inline section, simply because there wasn't a GFM dialect present and I wanted to just experiment with it from a user-facing perspective.