Hi,
On 28/12/15 06:16, Saša Janiška wrote:
On Ned, 2015-12-27 at 18:50 -0500, Offray Vladimir Luna Cárdenas wrote:
Hiya,
Seems that the reasons exposed in this tread are: It predated
markdown, so was already used inside the community, and gives us
finer control on the overall markup language, including exporting
formats.
Nothing against it, but some features like footnotes are simply 'must'
for serious writing, at least in my domain.
Yes, that's why I use pandoc's markdown.
Two projects implement this idea Pandoc[2]
Yeah, Pandoc is great and it would be cool to have Pillar support for
it.
You could extend it via Abstract Syntax Trees with Pharo.
and Grav[3] and both use a combination of markdown and yaml.
Grav looks interesting, but I believe I simply want to leave PHP world.
:-)
I did for a lot of time, barely touching anything php related and, as I
said in the blog post about Nikola and Grav[1], I dislike the php syntax
and pragmatics. But this doesn't prevent the acknowledge and eventual
use of really good solutions made on php like dokuwiki, Question2Answer
and Grav. What I'm trying to do is to communicate with this solutions
without touching too much the php part, just using more standard formats
like Json, cvs, markdown and yaml.
[1] http://mutabit.com/offray/blog/es/entry/2015-10-06-grav-nikola-both
My bet is on pandoc (markdown+yaml) for writing almost anything, with
some advantages over pillar:
My main complaint to markdown is that it is not standard, despite many
attempts (or extensions).
That's why I recommending you pandoc's markdown variant. It has
extensive support for footnotes, bibliographic references, tables,
latex, a lot of exporting formats and extensibility via exporting and
manipulating the Abstract Syntax Tree. Pandoc is also used in Scholarly
markdown and Jupyter projects so you could use the markup language
variant with more people beyond this community.
b. It has support for bibliographic references, footnotes a a more
complete feature set.
I wonder how is it that despite being present for so long, it does miss
such features...
Well that's the cost of being part of a small community where not all
the projects can be developed beyond the interest and limitations of few
members. And that's why interaction with broader communities (for
example pandoc's one could be wise).
Have you considered to use Pillar markup with Nikola? That's one
option I'm considering if Pillar is going to get things liek footnotes
etc.
No. As I said in the previous referred blog post I will use Nikola for
self hosted IPython/Jupyter notebooks and Grav mostly everywhere in web
publishing. Using padoc's markdown as the default format gives me a lot
of interoperability between documentation systems. My bet for mixing
pharo related developments and pandoc is via the Abstract Syntax Tree
manipulations... at some point.
Ecstatic have more powerful things like a logic-less
approach to templating via mustache, that is neutral to the
underlaying language
That would be another 'pro' for Pillar markup+Nikola, although I belive
Jinja is sufficient for my web needs.
What I would like is to integrate Mustache in future web developments
using Teapot, and Pharo, but my documentation language in the back end
would be the same and more cross-community: markdown + yaml. So mustache
and abstract syntax trees is an argument for not caring too much about a
tightly integrated and Pharo only markup language.
Btw, let me say that I'm also inspired with Butterick and was
considering to use Racket for my project, but ended up here. :-)
Did you mean this:
http://practicaltypography.com/why-racket-why-lisp.html
I think that racket is a pretty interesting system and Pollen[2] is also
interesting for documentation. The idea of document as a program was
presented to me in the times when I used TeXmacs[3] and then Leo
Editor[4]. Now I'm trying to bridge several ideas of these technologies
with the Interactivity of IPython but using the flexibility and
understandability of Pharo/Moose/Roassal for my own interactive
documentation (alpha state) project[5][6]
[2] http://pollenpub.com/
[3] http://texmacs.org/
[4] http://leoeditor.com/
[5] http://mutabit.com/grafoscopio/index.en.html
[6]
http://mutabit.com/offray/static/blog/output/posts/grafoscopio-idea-and-initial-progress.html
So, while I think that choosing Pharo technologies is better for
making them more mature, tested and used, I also think that is
important to choose proper balance to know which combination of Pharo
technologies and external ones is adequate.
I didn't mention, but I was playing with Golang's Hugo for some time
which is also nice and, to me, preferrable over PHP.
Didn't know about that or TOML. As I said, your barely touch php with
grav, but the self-containment of Hugo and the easy syntax of TOML seem
like good arguments in favor of them for web publishing. The main
message here is that you can combine Pharo technologies with non Pharo
ones via standard markup languages like markdown or yaml (or toml) and
yet get extensibility in Pharo.
Cheers,
Offray
