Open kdeldycke opened 4 years ago
Isn't this just a matter of style? The lists are semantically the same whether or not there is a two-space indent. Saying it's a regression implies that it's buggy behavior, but it's not buggy, just different. Pandoc's legacy markdown_github won't preserve the spacing in the source either:
% pandoc -t markdown_github
[WARNING] Deprecated: markdown_github. Use gfm instead.
- hi
- there
^D
- hi
- there
Thanks @jgm for providing some balanced view. I might have been too fast calling that a bug.
You're right, the semantics are preserved by cmark
no matter how the lists are reformatted. cmark
does a good job wrapping long lines and keeps the semantics intact. Great tool, and thanks a lot for investing so much time maintaining it! ❤️
I'm less advocating for preserving the indention than having it constrained by the user. The later being performed via the --tab-stop
parameter in the case of pandoc
.
Now is that fair to requalify this issue as a feature request? In which case it can retitle it "Allow configurable list's leading spaces" or "Add a --tab-stop parameter". Then you can decide as a maintainer to consider this feature for future addition or not. I'm also ready to move that issue to pandoc
if you don't think it's not under cmark
scope.
Here is a simple Markdown list:
Re-wrapping this to a maximum length of 80 characters introduces 2 spaces before each lines:
Here I expect
cmark
to get rid of these leading spaces and render as such:Why? So we can fix a regression in
pandoc
. See how the previous flavor (markdown_github
) behaved in that situation compared to the new one (gfm
, based oncmark
):I guess this behaviour should be somewhat configurable in
cmark
aspandoc
does with the--tab-stop
parameter:For reference, here the version of
cmark
I'm using, installed withbrew
on macOS Catalina: