Re: [Pharo-dev] [Pharo-users] including Pillar in Pharo image by default
again, I think this is a discussion for pharo-dev. Please keep it there (is good discussion, btw ;) ). What about my proposal of including a tiny PetitParser? (it would be âInfimeParserâ :P) Esteban
On 14 Aug 2017, at 11:10, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi Tim,
The main benefit of relying on Pillar is that we control its syntax and can easily extend it for our purposes. Also, there was quite a bit of engineering invested in it, and even though we still need to improve it, there exists a pipeline that allows people to quickly publish books.
The figure embedding problem is one example of the need to customize the syntax and behavior, but this extensibility will become even more important for supporting the idea of moving the documentation inside the image. For example, the ability to refer to a class, method or other artifacts will be quite relevant soon especially that the editor will be able to embed advanced elements inside the text.
Cheers, Doru
On Aug 14, 2017, at 10:46 AM, Tim Mackinnon <tim@testit.works> wrote:
Hi Stef - I think yourâs is a fair requirement (in fact I hit something similar when doing a static website using a JS markdown framework - and this is why I mentioned Kramdown which adds a few extras to regular markdown - but it feels like it goes a bit too far).
My next item on my learning todo list was to try and replace that JS generator with something from Smalltalk - so I think we can possibly come up with something that ticks all the right boxes (Iâd like to try anyway).
Iâll keep working away on it and compare notes with you. I think with Pillar, it was more that things like headers, bold and italics are similar concepts but just use different characters - so I keep typing the wrong thing and getting frustrated particularly when we embrace Git and readme.md is in markdown.
Tim
On 13 Aug 2017, at 20:08, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Hi tim
I personally do not care much about the syntax but I care about what I can do with it (ref, cite, ... ) I cannot write books in markdown because reference to figures!!!!!! were missing.
And of course a parser because markdown is not really nice to parse and I will not write a parser because I have something else to do. I want to make pillar smaller, simpler, nicer.
Now if someone come up with a parser that parse for REAL a markdown that can be extended with decent behavior (figure reference, section reference, cite) and can be extended because there are many things that can be nice to have (for example I want to be able to write the example below) and emit a PillarModel (AST) we can talk to have another syntax for Pillar but not before.
[[[test 2+3
5 ]]]
and being able to verify that the doc is in sync.
Stef
On Sat, Aug 12, 2017 at 12:37 AM, Tim Mackinnon <tim@testit.works> wrote:
Of course, I/we recognise and appreciate all the work that's gone into docs in pillar - but I think it should be reasonably straightforward to write a converter as it is pretty closely related from what I have seen.
So I don't make the suggestion flippantly, and would want to help write a converter and get us to a common ground where we can differentiate on the aspects where we can excel.
Tim
Sent from my iPhone
On 11 Aug 2017, at 23:21, Peter Uhnak <i.uhnak@gmail.com> wrote:
A long time issue with Markdown was that there was no standardization (and when I used Pillar's MD export ~2 years ago it didn't work well).
However CommonMark ( http://spec.commonmark.org/0.28/ ) has become the de-facto standard, so it would make sense to support it bidirectionally with Pillar.
The readme.md that Peter is talking about is gfm markdown
Well, technically it is just a CommonMark, as I am not using any github extensions. (Github uses CommonMarks and adds just couple small extensions.)
Peter
-- www.tudorgirba.com www.feenk.com
âLive like you mean it."
Hi,
On Aug 14, 2017, at 3:51 PM, Esteban Lorenzano <estebanlm@gmail.com> wrote:
again, I think this is a discussion for pharo-dev. Please keep it there (is good discussion, btw ;) ).
What about my proposal of including a tiny PetitParser? (it would be âInfimeParserâ :P)
I am for it, but there will be some work to repackage PetitParser2. Also, I notice that the French lessons start to pay off :) Cheers, Doru
Esteban
On 14 Aug 2017, at 11:10, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi Tim,
The main benefit of relying on Pillar is that we control its syntax and can easily extend it for our purposes. Also, there was quite a bit of engineering invested in it, and even though we still need to improve it, there exists a pipeline that allows people to quickly publish books.
The figure embedding problem is one example of the need to customize the syntax and behavior, but this extensibility will become even more important for supporting the idea of moving the documentation inside the image. For example, the ability to refer to a class, method or other artifacts will be quite relevant soon especially that the editor will be able to embed advanced elements inside the text.
Cheers, Doru
On Aug 14, 2017, at 10:46 AM, Tim Mackinnon <tim@testit.works> wrote:
Hi Stef - I think yourâs is a fair requirement (in fact I hit something similar when doing a static website using a JS markdown framework - and this is why I mentioned Kramdown which adds a few extras to regular markdown - but it feels like it goes a bit too far).
My next item on my learning todo list was to try and replace that JS generator with something from Smalltalk - so I think we can possibly come up with something that ticks all the right boxes (Iâd like to try anyway).
Iâll keep working away on it and compare notes with you. I think with Pillar, it was more that things like headers, bold and italics are similar concepts but just use different characters - so I keep typing the wrong thing and getting frustrated particularly when we embrace Git and readme.md is in markdown.
Tim
On 13 Aug 2017, at 20:08, Stephane Ducasse <stepharo.self@gmail.com> wrote:
Hi tim
I personally do not care much about the syntax but I care about what I can do with it (ref, cite, ... ) I cannot write books in markdown because reference to figures!!!!!! were missing.
And of course a parser because markdown is not really nice to parse and I will not write a parser because I have something else to do. I want to make pillar smaller, simpler, nicer.
Now if someone come up with a parser that parse for REAL a markdown that can be extended with decent behavior (figure reference, section reference, cite) and can be extended because there are many things that can be nice to have (for example I want to be able to write the example below) and emit a PillarModel (AST) we can talk to have another syntax for Pillar but not before.
[[[test 2+3
5 ]]]
and being able to verify that the doc is in sync.
Stef
On Sat, Aug 12, 2017 at 12:37 AM, Tim Mackinnon <tim@testit.works> wrote:
Of course, I/we recognise and appreciate all the work that's gone into docs in pillar - but I think it should be reasonably straightforward to write a converter as it is pretty closely related from what I have seen.
So I don't make the suggestion flippantly, and would want to help write a converter and get us to a common ground where we can differentiate on the aspects where we can excel.
Tim
Sent from my iPhone
On 11 Aug 2017, at 23:21, Peter Uhnak <i.uhnak@gmail.com> wrote:
A long time issue with Markdown was that there was no standardization (and when I used Pillar's MD export ~2 years ago it didn't work well).
However CommonMark ( http://spec.commonmark.org/0.28/ ) has become the de-facto standard, so it would make sense to support it bidirectionally with Pillar.
The readme.md that Peter is talking about is gfm markdown
Well, technically it is just a CommonMark, as I am not using any github extensions. (Github uses CommonMarks and adds just couple small extensions.)
Peter
-- www.tudorgirba.com www.feenk.com
âLive like you mean it."
-- www.tudorgirba.com www.feenk.com "To lead is not to demand things, it is to make them happen."
participants (2)
-
Esteban Lorenzano -
Tudor Girba