commonmark / commonmark/commonmark-java
Option to define custom flanking/canOpen/canClose rules for delimiters
还没有人认领这个 Issue。
- 主要语言
- Java
- 星标
- 2.7k
- 派生
- 336
- PR 合并指标
- 30 天内没有已合并 PR
描述
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
贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
调研方向
从 InlineParserImpl 开始,跟踪 delimiter runs 如何变为 DelimiterData,以及 processDelimiters 如何调用 DelimitedProcessor.process()。检查 inlineParserFactory 路径,并确定在不复制 InlineParserImpl 的情况下,可以在哪里暴露自定义的 canOpen/canClose 或 flanking 行为。完成的标准是,consumer 可以定义自定义 delimiter 规则,并且能够按要求解析 loose 粗体和斜体语法。
由索引模型根据 Issue 内容生成。
评估
- 技术栈
- java
- 领域
- tooling
- Issue 类型
- 功能
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 活跃度
- 活跃
- 描述清晰度
- 基本清楚
- 新手友好度
- 45/100