Hi Tim, I had the same need for a more structured access to a parsed document. I believe this class does something to like that https://raw.githubusercontent.com/kasperosterbye/PillarDocumentEditor/master... My parser and that of pillar produce what you call "flat" parses, so this thing creates a superstructure on top of the actual tree, and leaves the actual tree intact. It seems I even made a gtInspector for the thing. If you find it useful, I can try and move it to the PillarRichTextRender and make the baseline or separate project. Best, Kasper On Thu, Mar 26, 2020 at 5:12 PM Tim Mackinnon <tim@testit.works> wrote:
Hey Kasper - it looks like your GHMParser does exactly what I need, in that it parses the markdown spec I am looking at.
One question - GHMAbstractBlock has a children property - when would you expect that to be populated?
E.g. if the markdown was
# Header 1
Some text
## Header 2
More text
## Header 3
Other text
Would you expect Header2 and 3 to be children of Header1? And equally the text blocks to be children of the respective headers?
At the moment they are just represented as a flat list - which I can use, but I was curious of your thoughts on that children property with respect to headings. Digging a bit more, it seems that only Lists use children (maybe thatâs right, but I always viewed markdown a bit like a structure document and hence the idea of sections having children too).
Iâll see how I get on, as this gives me a big leg up. If it does prove useful, might there be a possibility to either extract it into a separate project, or have a baseline group that just loads the parser?
Tim
On 25 Mar 2020, at 19:46, Kasper Osterbye <kasper.osterbye@gmail.com> wrote:
I do not think the PP2 is used in the github parser actually. The github parser was just a addon to the rest of the stuff, and the pillar markdown parser used PP2.
Anyways, if you have any questions, feel free to ask.
Best,
Kasper