Repository navigation
Option to define custom flanking/canOpen/canClose rules for delimiters #428
Description
Is your feature request related to a problem? Please describe.
The markdown spec that I'm trying to parse has loose rules when it comes to bold and italic delimiters, i.e. *italic * is vaild syntax. These seem to be the rules:
_- same behaviour as default__(as opener) - must have a space/punctuation on the left, but what's on the right doesn't matter__(as closer),*,**- no rules (can be surrounded by anything, can have spaces on either side, and still work)
However, Commonmark-java follows the default markdown spec which is strict and has certain flanking rules. Currently these rules seem to be hardcoded in InlineParserImpl:
boolean beforeIsPunctuation = before == Scanner.END || Characters.isPunctuationCodePoint(before);
boolean beforeIsWhitespace = before == Scanner.END || Characters.isWhitespaceCodePoint(before);
boolean afterIsPunctuation = after == Scanner.END || Characters.isPunctuationCodePoint(after);
boolean afterIsWhitespace = after == Scanner.END || Characters.isWhitespaceCodePoint(after);
boolean leftFlanking = !afterIsWhitespace &&
(!afterIsPunctuation || beforeIsWhitespace || beforeIsPunctuation);
boolean rightFlanking = !beforeIsWhitespace &&
(!beforeIsPunctuation || afterIsWhitespace || afterIsPunctuation);
boolean canOpen;
boolean canClose;
if (delimiterChar == '_') {
canOpen = leftFlanking && (!rightFlanking || beforeIsPunctuation);
canClose = rightFlanking && (!leftFlanking || afterIsPunctuation);
} else {
canOpen = leftFlanking && delimiterChar == delimiterProcessor.getOpeningCharacter();
canClose = rightFlanking && delimiterChar == delimiterProcessor.getClosingCharacter();
}
return new DelimiterData(delimiters, canOpen, canClose);
As far as I understand this cannot be solved with custom DelimitedProcessors, for DelimitedProcessor.process() to be called, canOpen() (which is calculated in the code snippet above) must be true in processDelimiters(Delimiter):
...
if (opener.canOpen() && opener.delimiterChar == openingDelimiterChar) {
potentialOpenerFound = true;
usedDelims = delimiterProcessor.process(opener, closer);
...
So in other words I couldn't find an easy way to change this behaviour.
Describe the solution you'd like
I would like for it to be possible to somehow define custom flanking rules for certain delimiter runs. Maybe the part in InlineParserImpl responsible for calculating canOpen/canClose and constructing DelimiterData could be lifted into an interface of some kind, or a public method in InlineParserImpl so that it can be inherited from and the method overriden.
Describe alternatives you've considered
Copying InlineParserImpl over to my project and changing the relevant lines, then using it via inlineParserFactory when building a Parser
Activity
robinst commentedon Apr 23, 2026
You might run into a lot of other incompatibilities if you're trying to parse Markdown from a different spec using commonmark-java..
Having said that, if we wanted to make this part pluggable, we might do it via some additions to
DelimiterProcessor, e.g.canOpenandcanClosemethods that get the before/after characters. Then add options to the parser to override the built-inAsteriskDelimiterProcessor/UnderscoreDelimiterProcessor.abhiramaab commentedon Aug 12, 2026
Hi @robinst, I'd like to work on this issue. I can implement the pluggable canOpen/canClose behavior discussed above, along with the necessary parser configuration and tests. Please let me know if you have any concerns with this approach before I start.
Emplexx commentedon Aug 20, 2026
Hmm, since you've mentioned overriding built in delimiter processors, am I correct in assuming this issue is blocked by #386 ? Would it be ok if I tried refining the PR that already exists for that issue, and made a PR for this one?
You might be right but despite that this library has still been extremely useful, and I really like the API it exposes, especially the Scanner
robinst commentedon Aug 23, 2026
Yes, that sounds good. Feel free to open a new PR just for that first. See my comment there: #432 (comment)
Then another PR for the API changes for this issue.