Native/abstracted sub-parsers

[ckiee]

Native/abstracted sub-parsers

[Marwes]

Could you post what kind of input you are trying to parse and how the output is expected to look like? I am not sure I understand it entirely, best I can tell the syntax seem rather ambigous.

**hi** // Could be parsed with the 1st and 4th `*` and the 2nd and 3rd as the start/end of a block or it could be parsed with the 1st and 2nd and the 3rd and 4th in the same block

With combine being LL it will consume eagerly so the first case (1+4 and 2+3) is the one that is parsed.

[ckiee]

Overall it's a mix of Org-mode and Markdown so 1+4 and 2+3 seem right, although they don't really have any special meaning and will just get optimized out later:

*hi*                         ; BlockExprNode::Bold(BlockExprNode::Text("hi"))
*/italics & bold/*           ; BlockExprNode::Bold(BlockExprNode::Italics(BlockExprNode::Text("italics & bold")))
**this is kinda useless**    ; BlockExprNode::Bold(BlockExprNode::Bold(BlockExprNode::Text("this is kinda useless")))

[Marwes]

If that is the case, why is bold calling itself recursively? Why not just (token('*'), many1(char()), token('*')) ?

[ckiee]

why is bold calling itself recursively?

Because eventually block_expr_node's choice! will have more options (like italics, etc..) so I'm just preparing it for that.

Ideally I could make block_expr_node's choice! skip bold in the second, nested call from bold but this isn't the reason I opened the issue. What do you think about the flat_map abstraction?

[Marwes]

It wouldn't be an unreasonable addition, however **this is kinda useless** would not be parsed as you expect with the and_reparse_with parser you showed, it would be parsed as Bold(""), Text("this is kinda useless"), Bold("") so I am not sure it is the solution you are looking for.

To parse it as BlockExprNode::Bold(BlockExprNode::Bold(BlockExprNode::Text("this is kinda useless"))) you would effectively need infinite lookahead to figure out which * are opening and closing a block which doesn't seem right.

Another solution may be to do something like (many1(choice(bold_char(), italics_char(), etc)).then(|prefix| text().skip(string(prefix.reverse()))) which would consume a "block prefix", then parse the text and finally check that the prefix appears in reverse order after.

[ckiee]

Another solution may be to do something like [..]

That would probably work, but you still need to treat hello* world as normal text (no matching bold_char) so it might be a bit more tricky.. For now I think I will leave this edge case alone since I want to get the whole pipeline kinda-working instead of parsing perfectly right away :P

It wouldn't be an unreasonable addition

Should I have a go at making a PR then? It seems tricky and I am still scared of all the types so I would need some mentoring probably