-
Notifications
You must be signed in to change notification settings - Fork 300
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for inline subparsers #263
Comments
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 #321 I'll keep this open until the change is released. |
🎉 Released in 0.23.0 now, see |
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.
The text was updated successfully, but these errors were encountered: