Hi, On 30/12/17 00:08, Dimitris Chloupis wrote:

For me Pillar has been the most underused feature of Pharo by far and it makes me sad how little we take advantage of this great technology.

I have argued time and again and in length about Markdown support in Pharo, so I will not do it again. I'll just repeat that, in order to make Pharo less isolated, Git support for managing software source code has the strategic importance, in the same way that Markdown support for managing documentation source code has strategic importance. This doesn't preclude support for native/alternative DVCS in the software front (Monticello, Fossil, etc) or markup languages in the documentation one (Pillar, Dokuwiki, t2tags, etc).

Pillar provides a feature set far longer and more important than markdown but I think as a community we need to not only include Pillar inside our standard distribution but built Pharo around it because it’s the perfect nerve center that unites so many massively popular documentation technologies like Markdown , LaTex, PDF and the usual suspect HTML.

The features are there. The only thing remaining is people using them.

Pandoc has a feature set far, far longer and more important that Pillar and Markdown, including Yaml metadata blocks, fine grained exportation control, ePub and a myriad of other output (an input) formats support (see graphic below), a community that is mostly devoted to discuss extensively/mainly a lightweight markup language for "full stack" documentation, scholarly Markdown community for academic writing, annotated Markdown for collaborative editing and writing, programmable templates, multilingual scripting support, including embedded one for Lua (which came pretty handy to import our most recently publication[1][1a]). And that  just to mention some prominent features in the greater feature set that just Pillar or Markdown provides. As community we need to not blind ourselves to alternatives and overcome the Not Invented Here Syndrome, to see value in what is done outside Pharo for documentation in the same way we have done for software management (specifically Git). A playground for Markdown will enhance Pandoc integration, which we already have in Grafoscopio, but writing medium to long texts in it, using the current plain text input objects support is cumbersome. Despite that we have managed to have long book sized texts redone in Grafoscopio in an agile way. The Data Driven Journalism Handbook [2] has 300+ pages (13 Mb PDF) in a single Grafoscopio notebook, stored under just a 600kb STON file (and a 500 kb exported Markdown file). [1] http://mutabit.com/repos.fossil/dataweek/uv/Artefactos/BibliotecaDigitalBogo... [1a] http://mutabit.com/repos.fossil/dataweek/doc/tip/Artefactos/BibliotecaDigita... [2] http://mutabit.com/repos.fossil/mapeda/ Several times, when I ask questions about Markdown, I'm pointed towards the Pillar existence, and I reiterate/expand my motives for wanting to implement *Markdown* support in Pharo. This exercise allow me to reiterate my questions in a more precise manner and hopefully this time someone will point me to a starting place about how to create a "playground for Markdown". Cheers, Offray

On Fri, 29 Dec 2017 at 22:56, Offray Vladimir Luna Cárdenas <offray.luna@mutabit.com <mailto:offray.luna@mutabit.com>> wrote:

Hi,

Playgrounds are a really good way to write short snippets of code and I wonder if such experience could be extended for larger pieces of Markdown. What I'm thinking of is have something similar but  like this:

1. Support for Markdown instead of Smalltalk, including syntax hightlighning and tab behavior (a tab equals two spaces).

2. Clicking on urls should load the respective web page. Clicking on images should  show an image preview.

That's it, to start with. At some point it could be using GT Documenter previews, font support and so on. But I would like to start by extending the playground to just support this two features. Any advice about where can I start for the first feature?

Thanks,

Offray

May be in pandoc community people helps each others. Sorry I could not resist. I want a system that we can maintain and debug. This is why we are removing make and bash scripts from pillar. Because this is not nice to fight with ugly generated bash files, believe me. stef On Sat, Dec 30, 2017 at 3:41 PM, Offray Vladimir Luna Cárdenas <offray.luna@mutabit.com> wrote:

I forgot the image about Pandoc import/export formats support. Here it is:

http://pandoc.org/diagram.jpg

Cheers,

Offray

On 30/12/17 09:29, Offray Vladimir Luna Cárdenas wrote:

Hi,

On 30/12/17 00:08, Dimitris Chloupis wrote:

For me Pillar has been the most underused feature of Pharo by far and it makes me sad how little we take advantage of this great technology.

I have argued time and again and in length about Markdown support in Pharo, so I will not do it again. I'll just repeat that, in order to make Pharo less isolated, Git support for managing software source code has the strategic importance, in the same way that Markdown support for managing documentation source code has strategic importance. This doesn't preclude support for native/alternative DVCS in the software front (Monticello, Fossil, etc) or markup languages in the documentation one (Pillar, Dokuwiki, t2tags, etc).

Pillar provides a feature set far longer and more important than markdown but I think as a community we need to not only include Pillar inside our standard distribution but built Pharo around it because it’s the perfect nerve center that unites so many massively popular documentation technologies like Markdown , LaTex, PDF and the usual suspect HTML.

The features are there. The only thing remaining is people using them.

Pandoc has a feature set far, far longer and more important that Pillar and Markdown, including Yaml metadata blocks, fine grained exportation control, ePub and a myriad of other output (an input) formats support (see graphic below), a community that is mostly devoted to discuss extensively/mainly a lightweight markup language for "full stack" documentation, scholarly Markdown community for academic writing, annotated Markdown for collaborative editing and writing, programmable templates, multilingual scripting support, including embedded one for Lua (which came pretty handy to import our most recently publication[1][1a]). And that just to mention some prominent features in the greater feature set that just Pillar or Markdown provides. As community we need to not blind ourselves to alternatives and overcome the Not Invented Here Syndrome, to see value in what is done outside Pharo for documentation in the same way we have done for software management (specifically Git).

A playground for Markdown will enhance Pandoc integration, which we already have in Grafoscopio, but writing medium to long texts in it, using the current plain text input objects support is cumbersome. Despite that we have managed to have long book sized texts redone in Grafoscopio in an agile way. The Data Driven Journalism Handbook [2] has 300+ pages (13 Mb PDF) in a single Grafoscopio notebook, stored under just a 600kb STON file (and a 500 kb exported Markdown file).

[1] http://mutabit.com/repos.fossil/dataweek/uv/Artefactos/BibliotecaDigitalBogo... [1a] http://mutabit.com/repos.fossil/dataweek/doc/tip/Artefactos/BibliotecaDigita... [2] http://mutabit.com/repos.fossil/mapeda/

Several times, when I ask questions about Markdown, I'm pointed towards the Pillar existence, and I reiterate/expand my motives for wanting to implement *Markdown* support in Pharo. This exercise allow me to reiterate my questions in a more precise manner and hopefully this time someone will point me to a starting place about how to create a "playground for Markdown".

Cheers,

Offray

On Fri, 29 Dec 2017 at 22:56, Offray Vladimir Luna Cárdenas <offray.luna@mutabit.com> wrote:

...

Hi,

Playgrounds are a really good way to write short snippets of code and I wonder if such experience could be extended for larger pieces of Markdown. What I'm thinking of is have something similar but like this:

1. Support for Markdown instead of Smalltalk, including syntax hightlighning and tab behavior (a tab equals two spaces).

2. Clicking on urls should load the respective web page. Clicking on images should show an image preview.

That's it, to start with. At some point it could be using GT Documenter previews, font support and so on. But I would like to start by extending the playground to just support this two features. Any advice about where can I start for the first feature?

Thanks,

Offray

As community we need to not blind ourselves to alternatives and overcome the Not Invented Here Syndrome, to see value in what is done outside Pharo for documentation in the same way we have done for software management (specifically Git).

+1

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

Sean, I don't think there is any conflict between having Pillar and Markdown support inside Pharo. I tried to explain myself as many times as I can, but time and again when Markdown gets mentioned, the next is "we already have Pillar" and then a holy war restarts because someone wants another markup system supported. All the old arguments for Pillar are mentioned and all about (Pandoc's) Markdown ignored and we, the community, rinse an repeat as a broken record. At least this time I know about support existing CommonMark. So maybe in 100 to 1000 iterations more of the above community cycle, we could have a versatile playground supporting at least two documentation markup systems and will be closer to a rich text/document editor system on Pharo. Cheers, Offray On 30/12/17 14:58, Sean P. DeNigris wrote:

Stephane Ducasse-3 wrote

...

Pillar is not about syntax but about the text model and all the visitors. Ah! Good to know. I was also confused on this point. Since we don't yet have a rich text editor, I only ever see static markup and static exports. I should take a deeper look.

That said, is there really a conflict with what Offray is saying/doing? IIUC he wants to create a Markdown parser, which presumable could be used to import into the Pillar model (I would assume when the tools become attractive enough to encourage this) and back out to Markdown for interoperability, no? Or am I missing something?

----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Thanks Glenn. It's nice to know that this community has at least 3 members that have no problem with adding *extra* support for Markdown (not killing Pillar) :-). I see that many of your examples come from scientific computing environments (R, Jupyter, Stata). If you're interested in reproducible research with Markdown support in Pharo, you could check Grafoscopio [1]. We have made complete books contained in a single Grafoscopio notebook (see [2]) thanks to the outline capabilities we have in the notebook. It's a feature I have not seen in other scientific computing systems, including Mathematica, Jupyter, R, and I'm aware of being available only on Org Mode and Leo Editor (and of course, Grafoscopio). Having complex (book size) documents organized in single diff-friendly files is very powerful. The integration of Pandoc's Markdown and interactive playgrounds in the Grafoscopio interactive notebooks create a unique computing experience. And because of the self-referential properties of the environment we can put all metadata inside the notebook, as playgrounds of Pharo dictionaries. We don't even use external bash or json config files and all the information for creating a particular output, including external commands are all expressed using just Pharo code. This is how we're creating the (Grafoscopio backed) books & publications. [1] http://mutabit.com/grafoscopio/index.en.html [2] http://mutabit.com/repos.fossil/mapeda/ I think that Smalltalk systems are pretty well suited for reproducible research, because of their self-contained nature and the image concept that allow you to "freeze" a whole computing environment and recover it intact decades later (as we discussed/exemplified in a couple of threads[3][4] recently) and this will be a hot topic in upcoming research on several fronts (science, journalims, activism, etc). This will be improved with Pharo 7 and the possibility to bootstrap the environment from a zero stage. Now imagine if that could be coupled with functional package managers (Chocolatey, Nix, Guix) and a widespread and used light markup language. It could bring a lot of worthy and diverse people to Pharo. It has already done that in a little scale at our local hackerspace [5]. I just want to start with proper support for Markdown inside a more diverse language aware Playground (and helping to build it). [3] https://twitter.com/khinsen/status/938719570235482112 [4] https://twitter.com/khinsen/status/938801977462591490 [5] http://mutabit.com/dataweek/ So yes, the past, present and current efforts for Pillar and Markdown support are worthy and opening a really interesting scenario. Cheers, Offray On 30/12/17 16:41, Glenn Hoetker wrote:

Offray et al,

Cheers to all who want to add more Markdown capabilities to Pharo. As a relatively new user who thinks Pharo is one of the coolest systems on Earth, I would love to see such. I don’t think it is a coincidence that so many new apps/language/etc. brag about Markdown capabilities (e.g., R lets you write Markdown, Stata—a stats DSL—has increased its Markdown capabilities, Jupyter Notebook/Lab has Markdown cells to make writing reproducible analyses easier, Apple’s Swift has added Markdown-derived documenting features, the iThought mind-mapping program uses Markdown for formatting, etc.). Despite the diversity of flavors and certain limitations, Markdown has (Markdowns have??) clearly become a lingua franca for the larger programming community. Other humane markup systems like ReStructuredText seem to be more narrow in appeal (e.g., RST in Python). My personal hunch is that popularity comes from its ease to write, read as plain text and process using any toolchain aimed at plain text.

Many of the things I’ve come to love about Pharo—images, coding and browsing in the System Browser, the versioning system—are, frankly, barriers to entry for the novice. Taking Pillar’s strengths and role in making Pharo more self-contained as given, it is still one more barrier to entry. How great it would be to provide an easier entry path via Markdown, even if we expect/hope folks will move to Pillar when they need more and have built up some overall comfort!!!

Also, the GFM dialect of Markdown is a key part of the Github ecosystem. So, Markdown would seem to have at least symbolic—and perhaps practical—synergies with efforts to integrate with Git.

Of somewhat less importance, there is an image factor. I personally haven’t seen tremendous value in having a Markdown parser in Python, Swift, GoLang, Racket, etc., but it seems like every language except COBOL and, maybe, BrainF**k now has a Markdown parser.

Lastly, I sense a concern that Markdown might displace Pillar for many users, draining energy away from it. On the one hand, that would indicate that it was better serving the needs of, say, 80% of the users despite being less capable than Pillar. On the other hand, what to do for the remaining 20% is a legitimate concern. On the third hand, letting the perfect be the enemy of the good often doesn’t work out well.

Which dialect of Markdown gets used seems less important than being able to handle **a** dialect, whichever it is. If Offray is going to do the work, seems like it is his choice. (That said, I’m *really* fond of the Pandoc dialect, even if GFM is most synergistic with Git-ward momentum.)

Many thanks to all for their past, current and future efforts on both Markdown and Pillar.

Glenn

Sent from my iPad

...

On Dec 30, 2017, at 1:18 PM, Offray Vladimir Luna Cárdenas <offray.luna@mutabit.com> wrote:

Sean,

I don't think there is any conflict between having Pillar and Markdown support inside Pharo. I tried to explain myself as many times as I can, but time and again when Markdown gets mentioned, the next is "we already have Pillar" and then a holy war restarts because someone wants another markup system supported. All the old arguments for Pillar are mentioned and all about (Pandoc's) Markdown ignored and we, the community, rinse an repeat as a broken record.

At least this time I know about support existing CommonMark. So maybe in 100 to 1000 iterations more of the above community cycle, we could have a versatile playground supporting at least two documentation markup systems and will be closer to a rich text/document editor system on Pharo.

Cheers,

Offray

...

On 30/12/17 14:58, Sean P. DeNigris wrote: Stephane Ducasse-3 wrote

...

Pillar is not about syntax but about the text model and all the visitors. Ah! Good to know. I was also confused on this point. Since we don't yet have a rich text editor, I only ever see static markup and static exports. I should take a deeper look.

That said, is there really a conflict with what Offray is saying/doing? IIUC he wants to create a Markdown parser, which presumable could be used to import into the Pillar model (I would assume when the tools become attractive enough to encourage this) and back out to Markdown for interoperability, no? Or am I missing something?

----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Check the pillar markdown parser (not fully working). This is the place to start having a working parser. Stef On Sat, Dec 30, 2017 at 3:29 PM, Offray Vladimir Luna Cárdenas <offray.luna@mutabit.com> wrote:

Hi,

On 30/12/17 00:08, Dimitris Chloupis wrote:

For me Pillar has been the most underused feature of Pharo by far and it makes me sad how little we take advantage of this great technology.

I have argued time and again and in length about Markdown support in Pharo, so I will not do it again. I'll just repeat that, in order to make Pharo less isolated, Git support for managing software source code has the strategic importance, in the same way that Markdown support for managing documentation source code has strategic importance. This doesn't preclude support for native/alternative DVCS in the software front (Monticello, Fossil, etc) or markup languages in the documentation one (Pillar, Dokuwiki, t2tags, etc).

Pillar provides a feature set far longer and more important than markdown but I think as a community we need to not only include Pillar inside our standard distribution but built Pharo around it because it’s the perfect nerve center that unites so many massively popular documentation technologies like Markdown , LaTex, PDF and the usual suspect HTML.

The features are there. The only thing remaining is people using them.

Pandoc has a feature set far, far longer and more important that Pillar and Markdown, including Yaml metadata blocks, fine grained exportation control, ePub and a myriad of other output (an input) formats support (see graphic below), a community that is mostly devoted to discuss extensively/mainly a lightweight markup language for "full stack" documentation, scholarly Markdown community for academic writing, annotated Markdown for collaborative editing and writing, programmable templates, multilingual scripting support, including embedded one for Lua (which came pretty handy to import our most recently publication[1][1a]). And that just to mention some prominent features in the greater feature set that just Pillar or Markdown provides. As community we need to not blind ourselves to alternatives and overcome the Not Invented Here Syndrome, to see value in what is done outside Pharo for documentation in the same way we have done for software management (specifically Git).

A playground for Markdown will enhance Pandoc integration, which we already have in Grafoscopio, but writing medium to long texts in it, using the current plain text input objects support is cumbersome. Despite that we have managed to have long book sized texts redone in Grafoscopio in an agile way. The Data Driven Journalism Handbook [2] has 300+ pages (13 Mb PDF) in a single Grafoscopio notebook, stored under just a 600kb STON file (and a 500 kb exported Markdown file).

[1] http://mutabit.com/repos.fossil/dataweek/uv/Artefactos/BibliotecaDigitalBogo... [1a] http://mutabit.com/repos.fossil/dataweek/doc/tip/Artefactos/BibliotecaDigita... [2] http://mutabit.com/repos.fossil/mapeda/

Several times, when I ask questions about Markdown, I'm pointed towards the Pillar existence, and I reiterate/expand my motives for wanting to implement *Markdown* support in Pharo. This exercise allow me to reiterate my questions in a more precise manner and hopefully this time someone will point me to a starting place about how to create a "playground for Markdown".

Cheers,

Offray

On Fri, 29 Dec 2017 at 22:56, Offray Vladimir Luna Cárdenas <offray.luna@mutabit.com> wrote:

...

Hi,

Playgrounds are a really good way to write short snippets of code and I wonder if such experience could be extended for larger pieces of Markdown. What I'm thinking of is have something similar but like this:

1. Support for Markdown instead of Smalltalk, including syntax hightlighning and tab behavior (a tab equals two spaces).

2. Clicking on urls should load the respective web page. Clicking on images should show an image preview.

That's it, to start with. At some point it could be using GT Documenter previews, font support and so on. But I would like to start by extending the playground to just support this two features. Any advice about where can I start for the first feature?

Thanks,

Offray

Thanks Peter, I will start my explorations here. Cheers, Offray On 30/12/17 12:06, Peter Uhnák wrote:

...

 I have argued time and again and in length about Markdown support in Pharo  Check the pillar markdown parser (not fully working).

Jan Kurs made an extensive petitparser for CommonMark with tests and everything... it is not complete but it had support for most common stuff. So the best approach would be two write a visitor on top of this parser to output Pillar document model.

...

 You confuse form and contents.

Stef, would it make sense to name them differently? E.g. "Pillar" is the syntax and "Pier" the model (or some other name). Maybe it could reduce the confusion, and improve the dialog surrounding it. Because people use same word when then mean different things.

Cheers, Peter

On Sat, Dec 30, 2017 at 5:50 PM, Stephane Ducasse <stepharo.self@gmail.com <mailto:stepharo.self@gmail.com>> wrote:

Check the pillar markdown parser (not fully working). This is the place to start having a working parser.

Stef

On Sat, Dec 30, 2017 at 3:29 PM, Offray Vladimir Luna Cárdenas <offray.luna@mutabit.com <mailto:offray.luna@mutabit.com>> wrote: > Hi, > > On 30/12/17 00:08, Dimitris Chloupis wrote: > > For me Pillar has been the most underused feature of Pharo by far and it > makes me sad how little we take advantage of this great technology. > > > I have argued time and again and in length about Markdown support in Pharo, > so I will not do it again. I'll just repeat that, in order to make Pharo > less isolated, Git support for managing software source code has the > strategic importance, in the same way that Markdown support for managing > documentation source code has strategic importance. This doesn't preclude > support for native/alternative DVCS in the software front (Monticello, > Fossil, etc) or markup languages in the documentation one (Pillar, Dokuwiki, > t2tags, etc). > > Pillar provides a feature set far longer and more important than markdown > but I think as a community we need to not only include Pillar inside our > standard distribution but built Pharo around it because it’s the perfect > nerve center that unites so many massively popular documentation > technologies like Markdown , LaTex, PDF and the usual suspect HTML. > > The features are there. The only thing remaining is people using them. > > > Pandoc has a feature set far, far longer and more important that Pillar and > Markdown, including Yaml metadata blocks, fine grained exportation control, > ePub and a myriad of other output (an input) formats support (see graphic > below), a community that is mostly devoted to discuss extensively/mainly a > lightweight markup language for "full stack" documentation, scholarly > Markdown community for academic writing, annotated Markdown for > collaborative editing and writing, programmable templates, multilingual > scripting support, including embedded one for Lua (which came pretty handy > to import our most recently publication[1][1a]). And that  just to mention > some prominent features in the greater feature set that just Pillar or > Markdown provides. As community we need to not blind ourselves to > alternatives and overcome the Not Invented Here Syndrome, to see value in > what is done outside Pharo for documentation in the same way we have done > for software management (specifically Git). > > A playground for Markdown will enhance Pandoc integration, which we already > have in Grafoscopio, but writing medium to long texts in it, using the > current plain text input objects support is cumbersome. Despite that we have > managed to have long book sized texts redone in Grafoscopio in an agile way. > The Data Driven Journalism Handbook [2] has 300+ pages (13 Mb PDF) in a > single Grafoscopio notebook, stored under just a 600kb STON file (and a 500 > kb exported Markdown file). > > [1] > http://mutabit.com/repos.fossil/dataweek/uv/Artefactos/BibliotecaDigitalBogo... <http://mutabit.com/repos.fossil/dataweek/uv/Artefactos/BibliotecaDigitalBogo...> > [1a] > http://mutabit.com/repos.fossil/dataweek/doc/tip/Artefactos/BibliotecaDigita... <http://mutabit.com/repos.fossil/dataweek/doc/tip/Artefactos/BibliotecaDigita...> > [2] http://mutabit.com/repos.fossil/mapeda/ <http://mutabit.com/repos.fossil/mapeda/> > > Several times, when I ask questions about Markdown, I'm pointed towards the > Pillar existence, and I reiterate/expand my motives for wanting to implement > *Markdown* support in Pharo. This exercise allow me to reiterate my > questions in a more precise manner and hopefully this time someone will > point me to a starting place about how to create a "playground for > Markdown". > > Cheers, > > Offray > > On Fri, 29 Dec 2017 at 22:56, Offray Vladimir Luna Cárdenas > <offray.luna@mutabit.com <mailto:offray.luna@mutabit.com>> wrote: >> >> Hi, >> >> Playgrounds are a really good way to write short snippets of code and I >> wonder if such experience could be extended for larger pieces of >> Markdown. What I'm thinking of is have something similar but  like this: >> >> 1. Support for Markdown instead of Smalltalk, including syntax >> hightlighning and tab behavior (a tab equals two spaces). >> >> 2. Clicking on urls should load the respective web page. Clicking on >> images should  show an image preview. >> >> That's it, to start with. At some point it could be using GT Documenter >> previews, font support and so on. But I would like to start by extending >> the playground to just support this two features. Any advice about where >> can I start for the first feature? >> >> Thanks, >> >> Offray >> >> >> >

Can you explain to me the abstractions you mention about pandoc because I'm curious? BTW you did not say: Ok guys I want to write a Markdown parser (to contribute to pillar, which would be cool.) You said I want to have a playground to edit markdown. This is quite different to me. About the not invented syndrome remarks, why then don't we drop Pharo? Now if each time we want to install pharo we should install Python, why not installing lua and Ruby and a bit of Javascript in case. You are under estimating the effort that we put in Pillar. We extracted pillar from pier to be able to have an autonomous document system with which we can write good pdf and good HTML for documentation point of view. Because people did not like to write in LaTeX. Now if we would stop something each time somebody mention something else we would be doing python, Javascript or ... all the time. So yes I'm dense and I focus on my stuff and my stuff is Pharo. And yes I do not care about pandoc because I want to write my exporters and tools in Pharo and I will fight for that. This is why I want to use Scale instead of *&%*^)&%^ bash. And this is why I spent most of time trying to improve Pharo because it is not at the level I want but I can contribute and make it better. Stef On Sat, Dec 30, 2017 at 10:15 PM, Stephane Ducasse <stepharo.self@gmail.com> wrote:

...

Jan Kurs made an extensive petitparser for CommonMark with tests and everything... it is not complete but it had support for most common stuff. So the best approach would be two write a visitor on top of this parser to output Pillar document model.

Good to know. I will see if we can ask students to do something we have a lecture that starts first week or we could ask asbath. (why a visitor? you mean that he already has production rules that outputs a tree?).

...

Stef, would it make sense to name them differently? E.g. "Pillar" is the syntax and "Pier" the model (or some other name). Maybe it could reduce the confusion, and improve the dialog surrounding it. Because people use same word when then mean different things.

I do not have the energy for that. Pharo it is the system or the syntax?

And yes I do not care about pandoc because I want to write my exporters and tools in Pharo and I will fight for that. +1

you forget impedence mismatch and reducing accidental complexity. Now I really hope that we will be able to have Pharo inside a dll so that we can embed everywhere and a much better interaction with OS and libraries out there. But if you get access to a C library you have to pay the price of the API exposition and glue. Stef On Sun, Dec 31, 2017 at 4:41 AM, Kjell Godo <squeaklist@gmail.com> wrote:

i like Pharo and i want Pharo to do well and i want to use Pharo and i like very much all the work being done on Pharo yes I’m very impressed and hopeful and i would not wish for that to slow down but can Pharo do everything by itself? i don’t think so i used to feel like i could not leave Smalltalk and andy’s comments and bullet proof correctness because the outside world was such a barrier to entry and the outside world was always missing something that makes Smalltalk essential and so i felt like i could not use those other things but if Smalltalk could be added to those other things then they could be ok and i could see using them like Racket clojure CommonLisp Shen Coq Haskell SwiProlog StrawberryProlog Pixie Forth Factor etc Ruby except it’s got a hell of a syntax erlang if Smalltalk could be added to them then they could be ok but without Smalltalk they look just like hell to me what a travesty unusable i don’t like anything that smells like C all the C like like java etc although turbo C was very nice so they had to kill it get rid of it because it’s like they are so inferior and yet everybody’s first language is just like the quick sand you sink right into never to be heard from again because God forbid you should have to go through that again once is enough so you sink right in never to be heard from again in any other venue and it’s like these were just the langs that worked first they got the network effect first and became the monopoly and that’s why people use them because God forbid for bid that you should learn something new we all say if Smalltalk could be like the front end of some other things Racket CommonLisp Shen etc then That is what i want and Smalltalk could be a back end too for things that it does well like i want to use gemstone etc

let everything do what it does best and let them all talk to each other is what i want that’s the BorgLisp idea

Hi, On 30/12/17 16:28, Stephane Ducasse wrote:

Can you explain to me the abstractions you mention about pandoc because I'm curious?

I think that the best places to start are the Filters documentation[1] and the Pandoc types package [2]. They essentially show how Pandoc provides structures to build a document programmaticaly including reading, exporting and manipulate it. Filters are explained in Haskell, but the documentation shows how you can use other languages to access the doc programmability. [1] http://pandoc.org/filters.html#summary [2] https://hackage.haskell.org/package/pandoc-types Quoting from the filters Summary: """ Pandoc consists of a set of readers and writers. When converting a document from one format to another, text is parsed by a reader into pandoc’s intermediate representation of the document—an “abstract syntax tree” or AST—which is then converted by the writer into the target format. The pandoc AST format is defined in the module |Text.Pandoc.Definition| in pandoc-types <https://hackage.haskell.org/package/pandoc-types>. A “filter” is a program that modifies the AST, between the reader and the writer: |INPUT --reader--> AST --filter--> AST --writer--> OUTPUT| Filters are “pipes” that read from standard input and write to standard output. """

BTW you did not say: Ok guys I want to write a Markdown parser (to contribute to pillar, which would be cool.) You said I want to have a playground to edit markdown. This is quite different to me.

Because the second thing (Markdown support inside the Playground) is the one I want to contribute to Pharo(!), not to Pillar. Contributing should not be so hard, but each time I bring this theme is an uphill battle in just getting the initial exploration questions answered (because they're about Markdown and not about Pillar). I think that Markdown support in Pharo is healthy for Pharo and a meaningful learning experience for me. At least I should be able to test that by myself in this community with a little of support like "hey we have CommonMark inside PettitParser" or "here is how you increase the Playground Syntax support, by specializing this class". 

About the not invented syndrome remarks, why then don't we drop Pharo? Now if each time we want to install pharo we should install Python, why not installing lua and Ruby and a bit of Javascript in case.

Because is not an all or nothing proposal and it has never been. It's about Pharo *playing well with* others, not about *being replaced by* others. I don't see any worth in taking this stuff to the extremes. When someone advise me Pharo, I don't think that he/she is advising me to drop my operative system and to run Pharo from bare metal because you go the Pharo way or the No Way(!).

You are under estimating the effort that we put in Pillar. We extracted pillar from pier to be able to have an autonomous document system with which we can write good pdf and good HTML for documentation point of view. Because people did not like to write in LaTeX. Now if we would stop something each time somebody mention something else we would be doing python, Javascript or ... all the time.

I don't underestimate anyone's work. Nor in Pillar, nor in Pharo, nor in Pandoc. In fact trying to make them work better together and giving back to this community by making software with Pharo and teaching people Pharo (for free) are clear examples of my appreciation for the work done in several fronts, inside and outside Pharo. The choice of LaTeX and HTML in your case, shows practical appreciation for those formats and I don't think that we should reimplement them in Pharo (despite of several advantages of live objects as documents instead of dead-files). Instead of putting valuations I have never done on me, I would advice to try seeing worth in the reasons behind a lot of people outside this community is using (Pandoc's) Markdown for documentation and the added value that adding Markdown support brings by having more people exposed to Pharo ecosystem, ideas, community, values and technology.

So yes I'm dense and I focus on my stuff and my stuff is Pharo. And yes I do not care about pandoc because I want to write my exporters and tools in Pharo and I will fight for that.

But we don't need to fight for that. I value your decisions and work and I think that is healthy to ask for reciprocity and build from that, instead of wasting time because we don't think the same. Diversity is healthy in a community. The only thing I'm asking for (besides such reciprocity) is pointers to start *my* exploration.

This is why I want to use Scale instead of *&%*^)&%^ bash. And this is why I spent most of time trying to improve Pharo because it is not at the level I want but I can contribute and make it better.

Stef

I don't use bash or Json config files for anything related with documentation in Grafoscopio. Just plain Pharo inside an interactive "%metadata" playground node in the Grafoscopio notebook. Spoon, Coral, Scale, would be welcomed when integration with them is ready. I spent good time also trying to make my contributions and improvements to Pharo. We don't need to fight because our ways of contribution are different. Cheers, Offray

Hi, On 31/12/17 05:13, Stephane Ducasse wrote:

...

from one format to another, text is parsed by a reader into pandoc’s intermediate representation of the document—an “abstract syntax tree” or AST—which is then converted by the writer into the target format. The pandoc AST format is defined in the module Text.Pandoc.Definition in pandoc-types.

A “filter” is a program that modifies the AST, between the reader and the writer:

INPUT --reader--> AST --filter--> AST --writer--> OUTPUT

Filters are “pipes” that read from standard input and write to standard output. """ FYI Pillar has the following architecture

Input --Reader -> AST -> (Transformer -> AST)* -Outputers (visitor) -> Save

So nothing new under the sun. Notice that we can do several transformation passes like expansions.

Cool. As I said in this thread in response to Stephan Eggermont, my concern is not about new under the sun, but in bridging cultural practices.

...

BTW you did not say: Ok guys I want to write a Markdown parser (to contribute to pillar, which would be cool.) You said I want to have a playground to edit markdown. This is quite different to me.

Because the second thing (Markdown support inside the Playground) is the one I want to contribute to Pharo(!), not to Pillar. Contributing should not be so hard, but each time I bring this theme is an uphill battle in just getting the initial exploration questions answered (because they're about Markdown and not about Pillar). So you will code your own text Model, AST, and visitor? Did you see that GT people are using Pillar model for the their editor?

I don't need to. I will use CommonMark and PettitParser. I imagine GT-Tools can use the models there in the Playground.

Go ahead and learn.

Wow! Finally!

...

About the not invented syndrome remarks, why then don't we drop Pharo? Now if each time we want to install pharo we should install Python, why not installing lua and Ruby and a bit of Javascript in case.

Because is not an all or nothing proposal and it has never been. It's about Pharo *playing well with* others, not about *being replaced by* others. I don't see any worth in taking this stuff to the extremes. When someone advise me Pharo, I don't think that he/she is advising me to drop my operative system and to run Pharo from bare metal because you go the Pharo way or the No Way(!).

You are exagerating

That was precisely my point. To show the absurd of exaggeration. I don't think that proposing a versatile Playground that supports several syntax highlighting (and some supporting behavior) is the same as proposing to install everything, kill Pillar efforts or anything like that. In the same way that using Pharo doesn't mean stop using anything else. But proposing anything distinct from Pillar as a documentation *alternative* in Pharo is faced time and again with overreactions.

and more important under estimating the COST of using multiple systems. Let me take four simple cases

- We spend hours debugging Yaml to embedd bash into a travis (no debugger of course) and we failed while we try to understand why the validator went wrong and did not like space (we tried many many combinations of `"' and more. And gave up. Guille is much better than me and Andrew on bash and we all three failed.

- Pillar was using external mustache unix based library and I forced them at that time to use Norbert implementation and we can debug it. We can avoid to have bugs because converting a stream into a file then invoking make then reloading the file.

- Looking during two days for a bug in bash script that tells that eveyrthing is ok while one package that should have been loaded was dropped. Now we use metacello instead relying on bash now. Do you want more... I have tons of them like that ... Each time you have a different stack you had another level of complexity and it is not linear but exponential. This is the same with servers and processes.

Pillar archetypes were zipped on a Jenkins server that may be blocked from time to time. Smalltalkhub may be slow and the bash will continue without failing and your installation breaks. So we are flushing everything.

No more mustache on disc, no more spurious metadata, no more separate server, no more make (see below I was not even able to add one entry to the help), no more cp -r (that is not compatible on different OSes!!!). Just plain pharo as much as possible.

I use just plain Pharo as much as possible in Grafoscopio. I don't have any external bash, config, yaml file to produce a document. Jus plain Pharo dictionaries and dynamic arrays stored *inside* the notebook. I use Pandoc to import/export to several formats (a place where it is superb and without any closer competitor), we started to use some Lua scripts (which are already supported in Pandoc) to query/script its document model and I have thought in using Pharo Mustache to program the Pandoc Templates. So in my "borg approach" I glue Pharo to existing ecosystems (including techs and communities) to improve them, while making bridges between what they already know and what Pharo has to offer.

# Some shell magic to auto-document the main targets. To have a target appear in # the output, add a short, one-line comment with a double ## on the same line as # the target. # # See http://marmelab.com/blog/2016/02/29/auto-documented-makefile.html

I document targets as a "%metadata" node inside the Grafoscopio notebook. No shell magic beyond Pandoc one line flags.

...

You are under estimating the effort that we put in Pillar. We extracted pillar from pier to be able to have an autonomous document system with which we can write good pdf and good HTML for documentation point of view. Because people did not like to write in LaTeX. Now if we would stop something each time somebody mention something else we would be doing python, Javascript or ... all the time.

I don't underestimate anyone's work. Nor in Pillar, nor in Pharo, nor in Pandoc. In fact trying to make them work better together and giving back to this community by making software with Pharo and teaching people Pharo (for free) are clear examples of my appreciation for the work done in several fronts, inside and outside Pharo. The choice of LaTeX and HTML in your case, shows practical appreciation for those formats and I don't think that we should reimplement them in Pharo (despite of several advantages of live objects as documents instead of dead-files). Instead of putting valuations I have never done on me, I would advice to try seeing worth in the reasons behind a lot of people outside this community is using (Pandoc's) Markdown for documentation and the added value that adding Markdown support brings by having more people exposed to Pharo ecosystem, ideas, community, values and technology. The argument that Coca cola is good because many people drink it does not hold. You see Pythoners have their own systems with their own syntax. So what?

I'm not using such ad-populum argument. I'm talking about *bridges* to what people is already using (in the backend) so we can show and use Pharo with them (in the front end) for data storytelling.

Pandoc is the same as Pillar.

Maybe in the technical side, but with a more diverse and agile community devoted exclusively to think about light markup languages. Bridging with other communities shouldn't be seen as negative.

I do not care about the Pillar syntax. I care that this is implemented in Pharo. Now I will not write a markdown parser myself because I have what I need. if other people propose a not super complex parser for markdown then we can integrate it and let people use their own.

Well I just want Markdown syntax highlighting in the Playground (besides the current Smalltalk one). It amaze me how much resistance about what I want to explore and can be able to contribute, it's faced every time.

...

So yes I'm dense and I focus on my stuff and my stuff is Pharo. And yes I do not care about pandoc because I want to write my exporters and tools in Pharo and I will fight for that.

But we don't need to fight for that. Yes because we should do the web in Javascript and the math in R and .... This is always like that.

Well is not. Having bridges with R (like the ones we have now) doesn't preclude or diminish the work in Polymath. Or having Garage to bridge with external data bases doesn't preclude any work in native OODBs or bridges with JSON don't preclude any work STON. Having bridges with Pandoc/Markdown, doesn't preclude/diminish any work with Pillar. I have told this since the first thread about this subject, but you insist in a confrontational approach. I will not engage in it when both can coexist and be helpful for this and other communities.

I value your decisions and work and I

...

think that is healthy to ask for reciprocity and build from that, instead of wasting time because we don't think the same. Diversity is healthy in a community. The only thing I'm asking for (besides such reciprocity) is pointers to start *my* exploration.

Then explore. You can also learn from Pillar :) If you want to have a look the pipeline in version 5 is obscrure and in the new pipeline guille dramatically cleaned it. and we will continue.

I will start my exploration with PetitParser and CommonMark.

...

This is why I want to use Scale instead of *&%*^)&%^ bash. And this is why I spent most of time trying to improve Pharo because it is not at the level I want but I can contribute and make it better.

Stef

I don't use bash or Json config files for anything related with documentation in Grafoscopio. Just plain Pharo inside an interactive "%metadata" playground node in the Grafoscopio notebook. Spoon, Coral, Scale, would be welcomed when integration with them is ready. I spent good time also trying to make my contributions and improvements to Pharo. We don't need to fight because our ways of contribution are different. Ok try and learn.

That's all I want: explore and learn. I finally have pointers to where to start. It just be more fluent if I don't have to fight an uphill battle anytime Markdown support is mentioned. Cheers, Offray

On Sun, Dec 31, 2017 at 4:00 PM, Sean P. DeNigris <sean@clipperadams.com> wrote:

Offray Vladimir Luna Cárdenas-2 wrote

...

a versatile Playground that supports several syntax highlighting (and some supporting behavior)

That actually could be amazing because sometimes I'm forced to use other syntaxes (especially markups nowadays) and I'd probably be much happier editing Markdown in Pharo than in the GH web UI! This actually just reminded me of Lukas' Helvetia and Language Boxes. Offray, I have no idea if it's relevant or useful (the project was from 2009), but you may want to have a look. Here's one link: http://scg.unibe.ch/research/helvetia

​We made a new version of Helvetia running on Pharo 5.0: https://github.com/UMMISCO/Helvetia ​Not currently updated to Pharo 6.1 or 7.0 -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC/UY1) "Programs must be written for people to read, and only incidentally for machines to execute."http://www.doesnotunderstand.org/

Offray Vladimir Luna Cárdenas <offray.luna@mutabit.com> wrote:

Pandoc consists of a set of readers and writers. When converting a document from one format to another, text is parsed by a reader into pandoc’s intermediate representation of the document—an “abstract syntax tree” or AST—which is then converted by the writer into the target format. The pandoc AST format is defined in the module |Text.Pandoc.Definition| in pandoc-types <https://hackage.haskell.org/package/pandoc-types>.

A “filter” is a program that modifies the AST, between the reader and the writer:

|INPUT --reader--> AST --filter--> AST --writer--> OUTPUT|

Filters are “pipes” that read from standard input and write to standard output.

Perhaps just reading the original Pier and Magritte thesis work by Lukas Renggli would be helpful then. Anything new or better in Pandoc? Stephan

The pipeline was not really first class in lukas work. It was added incrementally. Now we have a real architecture. On Sun, Dec 31, 2017 at 1:59 PM, Stephan Eggermont <stephan@stack.nl> wrote:

Offray Vladimir Luna Cárdenas <offray.luna@mutabit.com> wrote:

...

Pandoc consists of a set of readers and writers. When converting a document from one format to another, text is parsed by a reader into pandoc’s intermediate representation of the document—an “abstract syntax tree” or AST—which is then converted by the writer into the target format. The pandoc AST format is defined in the module |Text.Pandoc.Definition| in pandoc-types <https://hackage.haskell.org/package/pandoc-types>.

A “filter” is a program that modifies the AST, between the reader and the writer:

|INPUT --reader--> AST --filter--> AST --writer--> OUTPUT|

Filters are “pipes” that read from standard input and write to standard output.

Perhaps just reading the original Pier and Magritte thesis work by Lukas Renggli would be helpful then. Anything new or better in Pandoc?

Stephan

Hi, On 31/12/17 06:47, Dimitris Chloupis wrote:

 

I have argued time and again and in length about Markdown support in Pharo, so I will not do it again. I'll just repeat that, in order to make Pharo less isolated, Git support for managing software source code has the strategic importance, in the same way that Markdown support for managing documentation source code has strategic importance. This doesn't preclude support for native/alternative DVCS in the software front (Monticello, Fossil, etc) or markup languages in the documentation one (Pillar, Dokuwiki, t2tags, etc).

It's kinda funny because me and Esteban have been very early on huge supporters of git and github when the rest of the community was mildly interested to passionately against it.  I have been very vocal about it, to the point of annoying people and being accused of just supporting a overhyped product. 4 years later working with git is the official way of doing things and we even have our very own github client in the image.

Well it's kinda funny to experience the same resistance in the documentation front that we have in the Git/GitHub, even using the same old arguments. I don't like Git/GitHub, but I understand the strategic importance of it for the community. In the documentation front, each time Markdown is mentioned (with any external tool that works with it) we restart from zero to have the same old arguments (just look at the current thread). [...]

My personal opinion on this is that using syntax for documentation in 2017 feels to me like stone age. We did not even do this in 1980. I will dare to predict and you can bookmark this post that Markdow will slowly disappear to be replaced with the proper way of doing documentation and that is through a dedicated documentation editor like Libreoffice.  Even Google docs seem to return in favour of Markdown.

In 1980 we don't have Wikipedia and more that 5 million of articles written using a light markup language (LML). We didn't have GitHub and several devs communities writing collaboratively documentation using same kind of languages. We didn't have Ulysses[2], Ghost[3] and other apps directed towards non-devs, but bloggers and writers, using/advocating plain text and LMLs to keep you focused on writing (not typography or margins) and being able to write in small form factor screens. So I see the return in favor of LML as a progress over complicated and bloated XML files or cumbersome verbose markup languages for documentation (and their supporting GUIs). [1] https://en.wikipedia.org/wiki/Wikipedia:Size_of_Wikipedia [2] https://ulyssesapp.com/ [3] https://ghost.org/

The wide range of documentation formats take only a tiny fraction of the market. Adobe may have lost the war with Flash but when it comes to PDF they have won and won it easily. 

EPub for example is the least relevant format nowadays, it used be widely popular format, nowhere near to pdf but popular indeed at the time of PDAs but then iPhone came out and killed it together with Flash. Nowdays is used mostly on Kindle which is also another device that has lost most of its popularity.

ePub is still important for librarians working on public access to several works, in places where people (fortunately) doesn't have and iPhone, like in the wide Global South, from Mexico to Patagonia and beyond. In fact, recently we have a talk in the Grafoscopio mailing list about exporting to ePub the Data Driven Journalist Handbook (with the Pandoc source it was just matter of changing one parameter and voilà).

I consider myself an expert on documentation because my day job is being a lawyer and basically what we do is we write complex technical documentation for courts. Especially my kind of lawyer that do not do criminal law. I am writing legal documentation in a week what takes our community to write in years. 

I have been also close to documentation since 2002 (and I like to write long before that). From 2004 to 2008 we have the biggest wiki collection of Spanish recipes and how-to's about FLOSS with 4000 community articles. Of course this was a project in the "Global South", so nobody noticed it then, and now it slept lost in the cyberspace and somebody's offline backup. I was the main translator of TeXmacs[4] documentation to Spanish. An interactive mathematical documentation system with multiple backens long before Jupyter. So yes, I'm pretty sure that this community contains a lot of expertise in the documentation front. [4] http://texmacs.org/

Microsoft Office has been monopolising our field to an extreme extend and I must be one of those rare exceptions that I use Libreoffice and quite frankly I dont blame them because it has its issues. 

No I am not a believer in Markdown which usage became relevant only because Github supported it out of the box. With Github Markdown is nothing.

Well, Markdown has several use cases beyond programmers and beyond GitHub, as shown above (most programmers fail to see this).

I am not a believer in LaText again, another specialised software that is used by a very specific community.  

I think its syntax is too verbose, but you don't need it all the time. You could write in (Pandoc's) Markdown (or Pillar) and tweak the parts you need using only LaTeX in the places you want, leveraging decades of experience in layout, templates, typography or kerning, without paying upfront expertise you don't need. So combining LML with LaTeX and its engines is pretty powerful (that's the approach used in most LML systems to produce PDFs).

I am not a believe in Pandoc, why bother with a million formats when only 2 dominate the market ?

Because people use them, and fortunately reality is not only about market dominance dictate and its simplistic view. To the wikipedians, the format that dominates their reality is the one in their wiki, as happens with any wiki engine user, with their particular syntax. A lot of small communities are better serve by their particular LML despite of the "global market" efforts to reduce reality to the two oligopolistic "options". [...]

Why ?

Because either they are unnecessary hard to use or limited to what they can do. 

You can have a combination of extensible LML that combine with HTML, LaTeX or YAML, so they're easy to learn and not so limited.

If it was up to me, Libreoffice would have been our official way of documentation and the only alternative would have been an in image editor probably leveraging the existing Libreoffice API.

I am a GUI guy, anything that helps me type less and visualise more its far better option to the alternatives. 

Fortunately this was a community decision and not up to a single person. Good luck with a XML diff for a document wrote among several authors(!). TeXmacs for me had a lot of potential: WYSIWYM edition, math typography, diverse interactive backends, S expression all the way down, Lisp (Guile) scripting. But, because of the time it started, the toolkit was kind of isolated with a lot of ad-hoc, in-house solutions in a small community (at the end some Qt front-end was implemented). With Pharo we have the advantage of a continuum between the app, the IDE, the document, and that's something nobody has so evolved until now (not even the people at Mathematica or Jupyter Lab) and that makes a huge difference in the future of the application and its adaptability to the future/context.

But I have never stopped anyone from doing anything nor I tried to discourage. 

I can guarantee to you the same people that have not embraced Pillar is extremely unlikely they will embrace Markdown and Pandoc. There are two things that coders hate a) Writing documentation b) Creating GUIs. This is not going to change any time soon. Well not this millennium at least. 

In any case whatever your goal I wish you very good luck. You are going to need it.  

Coders are not my target and I'm already having luck, because our small diverse local community is already using LML for documentation.  They're librarians, students, philosophers, historians, teachers, journalist, and even we have coders using it. So your millennium of skepticism and resistance have already expired, at least locally :-), which is why I bet on serendipity instead of luck (the encounter of luck, opportunity and preparation). Cheers, Offray