Closed kostix closed 1 year ago
Hey @kostix,
I've added back support for Go 1.17 (it'll probably also work with 1.16) in #70 so you should be able to upgrade to v3.
For this issue, mind checking out #71? If you can verify that that meets your needs, I'll merge and release it. You should be able to temporarily pin to that branch with:
go mod edit -replace github.com/Kunde21/markdownfmt/v3=github.com/Kunde21/markdownfmt/v3@four-spaces
go mod tidy
I've added back support for Go 1.17 (it'll probably also work with 1.16) in #70 so you should be able to upgrade to v3.
Yes, v3 with #70 builds just OK with Go 1.17.
For this issue, mind checking out #71? If you can verify that that meets your needs, I'll merge and release it.
I have verified that doing
md := goldmark.New()
mr := markdown.NewRenderer()
mr.AddMarkdownOptions(markdown.WithListIndentStyle(markdown.ListIndentUniform))
md.SetRenderer(mr)
md.Convert(...)
produces the output I need, which is correctly interpreted by flexmark-java
.
Thanks for your work!
Thanks, upgraded the dependency in my project to v3.1.0.
@kostix: Your mailbox (and alias) has a problem, I have sent on gmail too.
Can you answer me?
Thanks in advance.
I'm having an issue with v2.1.0 (can't switch to v3.0.0 as I have to support Go < 1.18):
Given this list (with the spaces replaced with Unicode Open Box characters for illustration purposes):
processing with
markdownfmt
yieldswhich makes certain compliant renderers, namely, https://github.com/vsch/flexmark-java produce a single list of four elements instead of an outer list of two elements, in which the first one contains a nested list.
I have found this section in the CommonMark 0.30 spec which says something about indentation in this mode, but honestly, I failed to grasp a clear idea from it, and anyway I'm not sure whether
markdownfmt
tries to follow CommonMark in this particular case or I've spotted a bug.If it's an attempt to implement a spec diverging from the original installment then the question is: is it possible to implement a renderer option controlling this behavior?
Honestly, once I've read the original Markdown spec, I've always used a TAB or four spaces for indentation purposes, so to me, the described behavior looks like a bug, but given that CommonMark's gobbledygook, I'm not so sure :shrug: