Add support for asymmetric delimiters

[jleyba]

org.commonmark.parser.DelimiterProcessor only supports inline elements with symmetric delimiters, like * and _ (or ~~ for strikethrough). I'd like to write an extension for inline elements with asymmetric delimiters (in my case, {}), but this is not possible with the current design.

I have considered using a org.commonmark.parser.PostProcessor, but I'd like my extension to be parsed with the same precedence as other inline elements.

[robinst]

Hey! So if we changed DelimiterProcessor to allow the start and end delimiter to be different, would that be enough for your use case?

Would be good to know a little bit more about what {} would need. E.g. * and _ use the concept of left and right-flanking delimiter runs. Would you want the same to apply to {}?

[jleyba]

Changing DelimiterProcessor to support different delimiters would be useful. I think it would also be fair to say all DelimiterProcessors are bound by left/right flanking rules.

At a higher level, how would someone add support for inline elements parsed with the same precedence as a link or code span? One concrete example would be using commonmark with javadoc-like tools. How would you parse {@code foo} or {@link SomeClass}?

[robinst]

Cool, let's do that change for DelimiterProcessor and see how well it works for the above case. Do you want to have a go at it? It should be fairly straightforward, and I can give you pointers if you're stuck.

For {@code foo} or {@link SomeClass}, it seems like you could already do that in a post-processing step by looking at the literals of the parsed Text nodes, and then splitting up the text nodes and inserting your own nodes in between.

If you'd want to do it by participating in the inline parsing (and there's good reasons for that), we'd need to add new APIs. There would need to be some way to trigger it (e.g. { in the above case), and then the custom inline parser could consume as many characters as it needs from the input, and then return control. That would be in line with how InlineParserImpl currently works.

[robinst]

Fixed, DelimiterProcessor can now specify different opening and closing delimiter characters. See DelimiterProcessorTest for an example using {}.

@jleyba Could you build from master and check to see if that works for your use case?

[robinst]

Released in 0.5.0.