Open brodock opened 5 years ago
This case has been explicitly documented by the author as expected behavior But, based on observations above, the results are quite different.
Should we update the gfm-parser
to mimic GitHub's current output or not is up for discussion.
/cc @gettalong
The original GFM parser targeted the GFM implementation of Github, not the CommonMark re-implementation. So you will have to make a trade-off between backwards compatibility and targeting the current CommonMark based implementation.
I'm fine if the parser gets changed to follow the current GFM implementation. Note, however, that this may involve quite some changes.
This is not reproducible on master
.
If you're facing this issue with kramdown-parser-gfm-1.0.1
, rest assured as the next release will have it fixed.
Closing..
Nope. This report is still valid..
Here are two examples with their expected output:
Input:
Output:
Input:
Output:
Current implementation:
Is able to successfully perform the first, but not the second case.
Here is an example running the two on commonmark:
is a complex strike through *test ~~with nestinginvolved* here~~.is a complex strike through *testwithout nestinginvolved* here.I believe I'm on the right direction here, but so far what I've manage to do was get the second example to work by breaking the first one.
What I did was base on the balanced parameters example, using some lookahead and lookbehind code: