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