again, I think this is a discussion for pharo-dev. Please keep it there (is good discussion, btw ;) ).
What about my proposal of including a tiny PetitParser? (it would be “InfimeParser” :P) Esteban > On 14 Aug 2017, at 11:10, Tudor Girba <tu...@tudorgirba.com> wrote: > > Hi Tim, > > The main benefit of relying on Pillar is that we control its syntax and can > easily extend it for our purposes. Also, there was quite a bit of engineering > invested in it, and even though we still need to improve it, there exists a > pipeline that allows people to quickly publish books. > > The figure embedding problem is one example of the need to customize the > syntax and behavior, but this extensibility will become even more important > for supporting the idea of moving the documentation inside the image. For > example, the ability to refer to a class, method or other artifacts will be > quite relevant soon especially that the editor will be able to embed advanced > elements inside the text. > > Cheers, > Doru > > >> On Aug 14, 2017, at 10:46 AM, Tim Mackinnon <tim@testit.works> wrote: >> >> Hi Stef - I think your’s is a fair requirement (in fact I hit something >> similar when doing a static website using a JS markdown framework - and this >> is why I mentioned Kramdown which adds a few extras to regular markdown - >> but it feels like it goes a bit too far). >> >> My next item on my learning todo list was to try and replace that JS >> generator with something from Smalltalk - so I think we can possibly come up >> with something that ticks all the right boxes (I’d like to try anyway). >> >> I’ll keep working away on it and compare notes with you. I think with >> Pillar, it was more that things like headers, bold and italics are similar >> concepts but just use different characters - so I keep typing the wrong >> thing and getting frustrated particularly when we embrace Git and readme.md >> is in markdown. >> >> >> Tim >> >>> On 13 Aug 2017, at 20:08, Stephane Ducasse <stepharo.s...@gmail.com> wrote: >>> >>> 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 >>>>> >>>> >>>> >>> >> >> > > -- > www.tudorgirba.com > www.feenk.com > > “Live like you mean it." > >
