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