You can do this yourself, the link where to do this is at the bottom of each email
On Mon, Sep 8, 2014 at 1:58 PM, Joel MaHarry <joel.maha...@ulrichmaharry.com > wrote: > please take me off of this interminable discussion > > *Digital and brand communications* > > .......................................................................................................................................... > Joel MaHarry | Creative Director > joel.maha...@ulrichmaharry.com > O (310) 504-1790 | D (310) 993.1334 > 1528 6th St., Suite 512 > Santa Monica, CA 90401 > www.ulrichmaharry.com > > ......................................................................................................................................... > > > On Sep 5, 2014, at 9:16 PM, John MacFarlane <j...@berkeley.edu> wrote: > > +++ Michel Fortin [Sep 05 14 17:07 ]: > > From an implementer point of view, unless a detailed standard is written > as a description of what your own parser does, you'll have to spend a lot > of time tweaking things to match that standard. By "a lot of time" I mean > more than what it took you to implement the parser in the first place. > Remember, it's always getting the last 20% that takes 80% of the time. So > you'll spend a lot of time to achieve some dubious tradeoff. Implementers > have better things to do with their time. > > So my conclusion is that if you want one or another Markdown flavor to > become the standard, you need to find a way for its implementation to be > included everywhere. But with all the diverse language ecosystem we have, > and with the varied needs of different communities using Markdown, that > seems quite difficult to achieve. I'd call that impossible. > > > Michel, > > What you did at the beginning, I gather, was to port (and then extend) > an existing implementation, Markdown.pl. The same will be possible with > CommonMark, which provides two implementations that use the same parsing > algorithm, one in portable C and one in 1540 lines of javascript (with > no library dependencies). The javascript implementation doesn't use any > unusual javascript features and should be straightforward to > port to other dynamic languages: perl, python, ruby, PHP. (Or you could > just use the javascript library client-side and skip the server-side > rendering.) Those who work with compiled languages will be able to use > the C library directly. > > The parsers are both fast and accurate. The original C parser I wrote > was about as fast as discount. An expert C coder is now working on > otimizing it and, without changing the algorithm, has managed to make it > about as fast as sundown, which is very fast indeed (0.01 seconds to > parse a 1MB document, for example). When optimization is complete, it > should be even faster. The javascript parser is also very fast (0.28 > seconds for the above-mentioned 1MB document, running in the Chrome > browser). By comparising, Markdown.pl takes 250 seconds on the same > input, and pandoc takes 3.19 seconds. > > John > > _______________________________________________ > Markdown-Discuss mailing list > Markdown-Discuss@six.pairlist.net > http://six.pairlist.net/mailman/listinfo/markdown-discuss > > > _______________________________________________ > Markdown-Discuss mailing list > Markdown-Discuss@six.pairlist.net > http://six.pairlist.net/mailman/listinfo/markdown-discuss > >
_______________________________________________ Markdown-Discuss mailing list Markdown-Discuss@six.pairlist.net http://six.pairlist.net/mailman/listinfo/markdown-discuss
