Hi,
On 30/12/17 11:47, Stephane Ducasse wrote: > Hello blind people > > You confuse form and contents. > May be you should try to understand. But you continue to get blind after all > everybody should carry its own cross and this is perfectly ok not to > try to understand. I could say the same about you, as continuously I have argued in favor of Pandoc's Markdown because of reasons that are not in competence with Pillar, but related with different ecosystems and features around it and I have talked about the coexistence of both. Once and again you ignore such points and reiterate yours. I understand the advantages of a native debugable solution (as I have argued), but is not because of that that I'm choosing Pandoc, and I have talked about implementing support for AST and other ways to improve *Pharo* documentation ecosystem by playing well with Pandoc. > > Pillar is not about syntax but about the text model and all the visitors. Yes. We have already talked about this several times. I understand that (see above or any of the talks where we have mention this). > We are working on a release of Pillar 70 but we are slow because busy > with other things. > Part of the effort is to redesign and remodularised the core model > since it grew too much with optional features. > But for that we needed to design the production pipeline and clean a > lot of problems (like relying on external bash files > and external servers, and saving mustache files while we can just use > stream and many more). I appreciate all that effort. > > Now where can I find a real robust parser of markdown written in Pharo > (with tests of course)? > I mean one that fully handles badly designed markdown? and one that I > can extend to support references and missing > things. I don't know. That was why I started where to start with. Peter already talked about CommonMark with tests support. > Because Pillar could use multiple input formats. Now I will not spend > MY time to write a parser. Why because I can write all the books > I want with Pillar and this is a "Soup of Stone" in Pillar dev. Again, is not about how you or anyone in the community should invest your/his/her time. Is about how can I spent mine. I was asking directions to experiment on that. > > Repeat after me: the domain is more important than the syntax. The > proof is that pillar can generate > slides, book, ascii, epub, markdown (but apparently the one of git, > yes because they are multiple ones). HTML, static web sites .... I also understand that. Pandoc AST provide interesting abstractions of the documentation domain and that's why it can generate/read as much output/input formats. > > I personally do not want to be tight to any external frameworks like pandoc. > > Stef Totally understandable. I'm not pointed the only path anyone this community should follow. I'm showing other paths, for those interested, that (again!) can be parallel to the ones we have or are developing (as said in previous mails). > PS: for the record, pillar syntax was invented in 2000. So please stop > to bash us about not invented here because this syntax > was invented before markdown was well-known. So check your sources > before insulting people. Yes. You already told that when the Pillar/Markdown theme came out (but seems that our conversations about these themes restart to zero with any new comment about this). Not Invented Here Syndrome is not only about precedence, but about relluctancy to any external or alien. It's in that sense that I'm using the phrase and not as means to insult anyone. But a pretty good indicator of such syndrome is when people feel personally insulted just when any non-native solution/tech is bring into the table (for reasons mentioned several times). Cheers, Offray
