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 > <[email protected] <mailto:[email protected]>> 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 > <[email protected] <mailto:[email protected]>> 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 > > <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 > > <http://mutabit.com/repos.fossil/dataweek/doc/tip/Artefactos/BibliotecaDigitalBogota/intro.md> > > [2] http://mutabit.com/repos.fossil/mapeda/ > <http://mutabit.com/repos.fossil/mapeda/> > > > > Several times, when I ask questions about Markdown, I'm pointed > towards the > > Pillar existence, and I reiterate/expand my motives for wanting > to implement > > *Markdown* support in Pharo. This exercise allow me to reiterate my > > questions in a more precise manner and hopefully this time > someone will > > point me to a starting place about how to create a "playground for > > Markdown". > > > > Cheers, > > > > Offray > > > > On Fri, 29 Dec 2017 at 22:56, Offray Vladimir Luna Cárdenas > > <[email protected] <mailto:[email protected]>> 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 > >> > >> > >> > > > >
