Hi tim I personally do not care much about the syntax but I care about what I can do with it (ref, cite, ... ) I cannot write books in markdown because reference to figures!!!!!! were missing.
And of course a parser because markdown is not really nice to parse and I will not write a parser because I have something else to do. I want to make pillar smaller, simpler, nicer. Now if someone come up with a parser that parse for REAL a markdown that can be extended with decent behavior (figure reference, section reference, cite) and can be extended because there are many things that can be nice to have (for example I want to be able to write the example below) and emit a PillarModel (AST) we can talk to have another syntax for Pillar but not before. [[[test 2+3 >>> 5 ]]] and being able to verify that the doc is in sync. Stef On Sat, Aug 12, 2017 at 12:37 AM, Tim Mackinnon <tim@testit.works> wrote: > Of course, I/we recognise and appreciate all the work that's gone into docs > in pillar - but I think it should be reasonably straightforward to write a > converter as it is pretty closely related from what I have seen. > > So I don't make the suggestion flippantly, and would want to help write a > converter and get us to a common ground where we can differentiate on the > aspects where we can excel. > > Tim > > Sent from my iPhone > >> On 11 Aug 2017, at 23:21, Peter Uhnak <i.uh...@gmail.com> wrote: >> >> A long time issue with Markdown was that there was no standardization (and >> when I used Pillar's MD export ~2 years ago it didn't work well). >> >> However CommonMark ( http://spec.commonmark.org/0.28/ ) has become the >> de-facto standard, so it would make sense to support it bidirectionally with >> Pillar. >> >>> The readme.md that Peter is talking about is gfm markdown >> >> Well, technically it is just a CommonMark, as I am not using any github >> extensions. >> (Github uses CommonMarks and adds just couple small extensions.) >> >> Peter >> > >
