On 2013-10-30, at 21:15, Sven Van Caekenberghe <s...@stfx.eu> wrote:
> > On 30 Oct 2013, at 20:09, Camillo Bruni <camillobr...@gmail.com> wrote: > >>>>> I’m not looking for simplicity, I’m looking for a good final product. >>>>> ePub shouldn’t be simpler, it’s just made for eBooks. >>>>> On the other hand there are editors with WYSIWYG support >>>>> like:http://1.bp.blogspot.com/-K2Q-tdVbPRI/UI08v7LhzHI/AAAAAAAAABY/vZ5LHjM6nb4/s1600/Screen+Shot+2012-10-28+at+10.07.03+AM.png >>>>> And of course there is iBooks Author that I mentioned. >>>>> >>>>> I’m not trying to convince, I’m just trying to understand why development >>>>> of a new syntax is better the reusing/extending existing one. Or why we >>>>> can’t use epub + sigil for example. >>>> >>>> I personally *love* Markdown, it is very easy/productive to write >>>> documentation in. >>>> >>>> But, >>>> >>>> - there are different, competing and conflicting Markdown variants >>>> - there is no official specification (OK, daring fireball, but he refuses >>>> to work with github, stack exchange) >>>> - there is no formal syntax specification, nowhere >>>> - it is very hard to write a parser, it is too loosely specified >>>> >>>> Pier syntax is not new, it is probably older than Markdown. >>>> >>>> As far as I am concerned, the most prolific/active authors get to decide, >>>> it is a simple as that. >>>> >>>> I am just hoping that their standalone parser and document model is high >>>> quality ;-) >>> >>> I have nothing against pier syntax. But imagine person coming from outside, >>> who used markdown to ask questions on stack overflow and write readmes on >>> github, and here he has to use a different syntax for the same purpose. >>> Just a thought about bringing new people into a community :) >> >> I agree with you 100%... plus I use markdown for webdoc => >> http://files.pharo.org/doc/2.0/ > > But do you agree on my list of technical problems with Markdown ? > > I once tried to write a Markdown parser myself and I gave up and you admit > that you don’t get yours in full order, so... > > And even if you did get it more or less right, you would get conflicting > feature requests. Sadly yes. We spent quite some time with Damien Pollet to get a better version, we ended up with a 2-pass approach to first detect blocks an then do the span analysis. This way you get quite far, but still, it is not very well defined.
signature.asc
Description: Message signed with OpenPGP using GPGMail