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