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