You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
AST nodes do not provide start or end indices into the source and Emphasis.java and StrongEmphasis.java do not provide delimiter infomation. Therefore, for the input:
Hello *Italic***Bold**_Emph___Strong__~~Strike~~!
It does not currently seem possible to parse this, build an AST, and emit the same markdown back out, as the metadata about the delimiter character is lost.
It would be cool to have a CommonMark renderer (cmark has one too)! There's probably more issues related to that, so I've created #12 to track these.
Would you be interested in contributing to this? This issue for example should be pretty simple to implement. Basically put the delimiter char on the node types (see EmphasisDelimiterProcessor).
(Excuse my not being responsive by the way, I'm currently on holidays.)
I thought that opener.getLiteral().charAt(0) would be sufficient in EmphasisDelimiterProcessor. Sometimes the opener literal is null however. Surprised me.
Yeah, that's a bit surprising. The reason is that the opener and closer nodes are truncated before calling the processor in InlineParserImpl. Maybe it would make sense to do this after calling the processor.
In this case though, you can call getDelimiterChar() in EmphasisDelimiterProcessor to get the character.
Activity
robinst commentedon Aug 10, 2015
It would be cool to have a CommonMark renderer (cmark has one too)! There's probably more issues related to that, so I've created #12 to track these.
Would you be interested in contributing to this? This issue for example should be pretty simple to implement. Basically put the delimiter char on the node types (see
EmphasisDelimiterProcessor).(Excuse my not being responsive by the way, I'm currently on holidays.)
pcj commentedon Aug 10, 2015
I thought that
opener.getLiteral().charAt(0)would be sufficient inEmphasisDelimiterProcessor. Sometimes the opener literal is null however. Surprised me.robinst commentedon Aug 17, 2015
Yeah, that's a bit surprising. The reason is that the opener and closer nodes are truncated before calling the processor in
InlineParserImpl. Maybe it would make sense to do this after calling the processor.In this case though, you can call
getDelimiterChar()inEmphasisDelimiterProcessorto get the character.robinst commentedon Feb 4, 2016
Fixed with #36.
robinst commentedon Apr 22, 2016
Released in 0.5.0.