Closed avarga closed 8 hours ago
Yeah it would be useful, but I've been hesitant to commit to an API for it before (in order not to have to break API if we need to change it). One major outstanding change is to enable round-trip parsing which will probably affect the API.
But we could enable support for it while keeping it "internal", meaning "It's not API yet and if you use it you might have to adjust your code on newer versions". I won't have time to work on it in the next few weeks though.
I just merged a change to implement this, see https://github.com/commonmark/commonmark-java/pull/321
I'll keep this open until the change is released.
🎉 Released in 0.23.0 now, see customInlineContentParserFactory
in Parser.Builder
. Full changelog: https://github.com/commonmark/commonmark-java/blob/main/CHANGELOG.md#0230---2024-09-16
I was trying to implement an extension that turns references denoted by a prefix character (@,#, or ~) into a link, and missing the means to do it. A PostProcessor won't do it, because I want the prefix characters to be escapable by backslash to take away their special meaning, and the info necessary for that doesn't survive into the AST. The Delimiter stuff isn't useful either, because we have no definite closing character.
The proper solution would be a sub-parser that is activated then the main parser sees the prefix character. This something that
InlineParserImpl
already does internally:but not only is
InlineParserImpl
in aninternal
package, but all relevant methods and fields are private as well, so I have no chance to use it even if I didn't care about backward compatibility.I suggest opening up an official way of adding sub-parsers to the internal parser.