A playground for Markdown?
Locked
12
12
A playground for Markdown?
 
|
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 |
|
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, |
Re: A playground for Markdown?
|
|
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. 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
|
Re: A playground for Markdown?
|
|
I forgot the image about Pandoc import/export formats support. Here it is: Cheers, Offray On 30/12/17 09:29, Offray Vladimir Luna
Cárdenas wrote:
|
|
|
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
|
Re: A playground for Markdown?
|
|
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 |
Re: A playground for Markdown?
|
|
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 >> >> >> > > |
Re: A playground for Markdown?
|
|
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 >> >> >> > |
|
|
> 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). |
Re: A playground for Markdown?
|
|
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 |
Re: A playground for Markdown?
|
|
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 |
Re: A playground for Markdown?
|
|
In reply to this post by Peter Uhnak
Thanks Peter, I will start my explorations here. Cheers, Offray On 30/12/17 12:06, Peter Uhnák wrote:
|
Re: A playground for Markdown?
|
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 |
Re: A playground for Markdown?
|
|
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 > > |
Re: A playground for Markdown?
|
|
In reply to this post by Peter Uhnak
> 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? |
Re: A playground for Markdown?
|
|
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? |
|
|
There was a visitor that produced HTML from the markdown, so the same could be done to produce pillar.
I tend to call "Pharo" the system, and "Smalltalk language" the syntax. |
|
|
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 >> >> > > > |
|
|
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
|
Re: A playground for Markdown?
|
|
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 >>> >>> >> >> > |
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |