New parser for Pillar about pillar

[jecisc]

I created a PetitPillar parser that works but it still depend on the old parser.
We need to improve that.

[DamienCassou]

I think job is done at 90% (nearly all tests pass). The remaining 10% are details here and there where the new parser still depends on some pieces of the old one. Maybe the simplest thing to do is to move the parts that are useful from the old parser to the new one and remove the old. Then, in a second step, we can rewrite these parts in petit parser.

[jecisc]

I removed the dependency of the annotation parser.

Dependencies left:

• figures
• links
• raw

[jecisc]

Dependencies left:

• Raw

[jecisc]

An independent version of PetitPillar is ready :)
This version need test on real chapter to see if we do not lack of tests and if the time of parse is correct with the recent changes.

[jecisc]

The old parser was able to parse ==\""bold""== but PetitPillar no. should we charge PetitPillar or do we expect the user to write ==\""bold\""== ? @DamienCassou

[jecisc]

For now PetitPillar have a problem if we have something as ==*== blabla ==*== I think. It creates 1 format with 1 internal link with == blabla == as reference.
The parse of the other contents of the format do not stop at the end of the format.

[jecisc]

Maybe the simpler would be to only have:

    boldFormat
        ^ boldMarkup, (escape / boldmarkup negate) star , boldMarkup

then re-parse the content to check formats, links, raw…

It's maybe not optimal but it will be hard to do better quickly.

[DamienCassou]

CyrilFerlicot [email protected] writes:

The old parser was able to parse ==\""bold""== but PetitPillar no.
should we charge PetitPillar or do we expect the user to write
\==bold\== ? @DamienCassou

when writing ==\""bold""==, we expect Pillar to construct this
structure:

PRMonospace
  PRText: ""bold""

I think we want to keep have a way to write something that will generate
this structure: it could as well be =="\"bold""==. If you make this
second example work, no need to make the first work as well. We will fix
the books.

On the contrary, \==bold\== should have this structure

PRText: ==bold==

Each time we find something not parsing in the book, we should add a
unit test to detect the problem sooner.

Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill

[DamienCassou]

CyrilFerlicot [email protected] writes:

For now PetitPillar have a problem if we have something as ==*== blabla ==*== I think. It creates 1 format with 1 internal link with == blabla == as reference.
The parse of the other contents of the format do not stop at the end of the format.

If the writer wants a * in mono space, he should protect it: ==\*== blabla ==\*==. If the write wants to have an equal-equal inside a mono
space, he should protect it: ==\*=\= blabla =\=\*==. If the user wants
an internal link in mono space, he should protect the equal-equal:
==*=\= blabla =\=*==.

Damien Cassou
http://damiencassou.seasidehosting.st

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill

[jecisc]

I updated the book and now the build pass :)

I think we can do a new configuration I think !

[jecisc]

Or maybe not… It seams we have some warnings we did not had before… I'll take a look later.

[jecisc]

Corrected !

[DamienCassou]

I validated the new parser on ReadyForReviews chapters. Everything is fine there as well

[DamienCassou]

and on InProgress chapters. Everything is fine there as well. I think we should release Pillar v2.0.0.

[jecisc]

:)

[jecisc]

Name: ConfigurationOfPillar-CyrilFerlicot.167
Author: CyrilFerlicot
Time: 11 September 2015, 12:05:10.764145 pm
UUID: 2af05692-ab27-3749-afc8-af3f061f6ccc
Ancestors: ConfigurationOfPillar-CyrilFerlicot.166