A playground for Markdown?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
35 messages Options
12
Reply | Threaded
Open this post in threaded view
|

A playground for Markdown?

Offray Vladimir Luna Cárdenas-2
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



Reply | Threaded
Open this post in threaded view
|

Re: A playground for Markdown?

kilon.alios
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.

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.
On Fri, 29 Dec 2017 at 22:56, Offray Vladimir Luna Cárdenas <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

Re: A playground for Markdown?

Offray Vladimir Luna Cárdenas-2

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/BibliotecaDigitalBogota/pasos-para-bidibog.pdf
[1a] http://mutabit.com/repos.fossil/dataweek/doc/tip/Artefactos/BibliotecaDigitalBogota/intro.md
[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 <[hidden email]> 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




Reply | Threaded
Open this post in threaded view
|

Re: A playground for Markdown?

Offray Vladimir Luna Cárdenas-2

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/BibliotecaDigitalBogota/pasos-para-bidibog.pdf
[1a] http://mutabit.com/repos.fossil/dataweek/doc/tip/Artefactos/BibliotecaDigitalBogota/intro.md
[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 <[hidden email]> 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





Reply | Threaded
Open this post in threaded view
|

Re: A playground for Markdown?

Kjell Godo
In reply to this post by Offray Vladimir Luna Cárdenas-2
> 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
Reply | Threaded
Open this post in threaded view
|

Re: A playground for Markdown?

Stephane Ducasse-3
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.

Pillar is not about syntax but about the text model and all the visitors.
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).

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.
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.

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 personally do not want to be tight to any external frameworks like pandoc.

Stef

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.


On Sat, Dec 30, 2017 at 4:19 PM, Kjell Godo <[hidden email]> wrote:
>> 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

Reply | Threaded
Open this post in threaded view
|

Re: A playground for Markdown?

Stephane Ducasse-3
In reply to this post by Offray Vladimir Luna Cárdenas-2
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
<[hidden email]> 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/BibliotecaDigitalBogota/pasos-para-bidibog.pdf
> [1a]
> http://mutabit.com/repos.fossil/dataweek/doc/tip/Artefactos/BibliotecaDigitalBogota/intro.md
> [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
> <[hidden email]> 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
>>
>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: A playground for Markdown?

Stephane Ducasse-3
In reply to this post by Offray Vladimir Luna Cárdenas-2
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
<[hidden email]> 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/BibliotecaDigitalBogota/pasos-para-bidibog.pdf
> [1a]
> http://mutabit.com/repos.fossil/dataweek/doc/tip/Artefactos/BibliotecaDigitalBogota/intro.md
> [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
> <[hidden email]> 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
>>
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: A playground for Markdown?

Peter Uhnák
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 <[hidden email]> 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
<[hidden email]> 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/BibliotecaDigitalBogota/pasos-para-bidibog.pdf
> [1a]
> http://mutabit.com/repos.fossil/dataweek/doc/tip/Artefactos/BibliotecaDigitalBogota/intro.md
> [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
> <[hidden email]> 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
>>
>>
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: A playground for Markdown?

Offray Vladimir Luna Cárdenas-2
In reply to this post by Stephane Ducasse-3


On 30/12/17 11:49, Stephane Ducasse wrote:
> May be in pandoc community people helps each others. Sorry I could not resist.

Yes. In that community they help each other. I was asking in *this*
community about Markdown support on two specific issues *inside Pharo*.
Some answers are coming on that front, after the classical deviation on
why everybody should use Pillar for documentation, if wants to be part
of this community.

>
> 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
>

I believe you. I found much more easier to use Pandoc + Grafoscopio that
Pillar + Grafoscopio, because of all those external dependencies. And I
say this after reading the documentation of both and using one
extensively not because of my prejudice against or in favor of a
particular markup. I want also a system that I can debug and maintain
and also play well with others. I think that having a more versatile
playground is better, not worse, including supporting several syntax and
markup languages. It seems not something against having such
maintainable systems, but in favor of it.

Cheers,

Offray


Reply | Threaded
Open this post in threaded view
|

Re: A playground for Markdown?

Offray Vladimir Luna Cárdenas-2
In reply to this post by Stephane Ducasse-3
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


Reply | Threaded
Open this post in threaded view
|

Re: A playground for Markdown?

Offray Vladimir Luna Cárdenas-2
In reply to this post by Peter Uhnák

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 <[hidden email]> 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
<[hidden email]> 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/BibliotecaDigitalBogota/pasos-para-bidibog.pdf
> [1a]
> http://mutabit.com/repos.fossil/dataweek/doc/tip/Artefactos/BibliotecaDigitalBogota/intro.md
> [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
> <[hidden email]> 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
>>
>>
>>
>



Reply | Threaded
Open this post in threaded view
|

Re: A playground for Markdown?

Sean P. DeNigris
Administrator
In reply to this post by Stephane Ducasse-3
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

Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: A playground for Markdown?

Offray Vladimir Luna Cárdenas-2
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
>
>



Reply | Threaded
Open this post in threaded view
|

Re: A playground for Markdown?

Stephane Ducasse-3
In reply to this post by Peter Uhnák
> 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?

Reply | Threaded
Open this post in threaded view
|

Re: A playground for Markdown?

Stephane Ducasse-3
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
<[hidden email]> 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?

Reply | Threaded
Open this post in threaded view
|

Re: A playground for Markdown?

Peter Uhnák
On Sat, Dec 30, 2017 at 10:15 PM, Stephane Ducasse
<[hidden email]> 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?).

There was a visitor that produced HTML from the markdown, so the same could be done to produce pillar.
 
>
>
>> 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?

I tend to call "Pharo" the system, and "Smalltalk language" the syntax.
 

Reply | Threaded
Open this post in threaded view
|

Re: A playground for Markdown?

ghoetker
In reply to this post by Offray Vladimir Luna Cárdenas-2
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 <[hidden email]> 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
>>
>>
>
>
>

Glenn Hoetker
ghoetker@me.com
http://hoetker.faculty.asu.edu
Reply | Threaded
Open this post in threaded view
|

Re: A playground for Markdown?

Kjell Godo
In reply to this post by Stephane Ducasse-3
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
Reply | Threaded
Open this post in threaded view
|

Re: A playground for Markdown?

Offray Vladimir Luna Cárdenas-2
In reply to this post by ghoetker
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 <[hidden email]> 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
>>>
>>>
>>
>>
>



12