Extra leading spaces when wrapping list to fixed width

[kdeldycke]

Here is a simple Markdown list:

❯ cat ./list.md
- [Link 1](#link-1) - Description of line 1.
- [Link 2](#link-2) - A very long description for the second link in the list. That description is more than 80 characters wide.
- [This is a very long title, pointing to an awesome article on incredible stuff we're not used to see everyday](#link-3) - Line #3's description.

Re-wrapping this to a maximum length of 80 characters introduces 2 spaces before each lines:

❯ /System/Volumes/Data/usr/local/opt/cmark/bin/cmark --to commonmark --width 80 ./list.md
  - [Link 1](#link-1) - Description of line 1.
  - [Link 2](#link-2) - A very long description for the second link in the list.
    That description is more than 80 characters wide.
  - [This is a very long title, pointing to an awesome article on incredible
    stuff we're not used to see everyday](#link-3) - Line \#3's description.

Here I expect cmark to get rid of these leading spaces and render as such:

- [Link 1](#link-1) - Description of line 1.
- [Link 2](#link-2) - A very long description for the second link in the list.
  That description is more than 80 characters wide.
- [This is a very long title, pointing to an awesome article on incredible stuff
  we're not used to see everyday](#link-3) - Line \#3's description.

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 on cmark):

❯ pandoc --version
pandoc 2.9.2.1
Compiled with pandoc-types 1.20, texmath 0.12.0.1, skylighting 0.8.3.2

❯ pandoc ./list.md --to=markdown_github
[WARNING] Deprecated: markdown_github. Use gfm instead.
-   [Link 1](#link-1) - Description of line 1.
-   [Link 2](#link-2) - A very long description for the second link in
    the list. That description is more than 80 characters wide.
-   [This is a very long title, pointing to an awesome article on
    incredible stuff we’re not used to see everyday](#link-3) - Line
    \#3’s description.

❯ pandoc ./list.md --to=gfm
  - [Link 1](#link-1) - Description of line 1.
  - [Link 2](#link-2) - A very long description for the second link in
    the list. That description is more than 80 characters wide.
  - [This is a very long title, pointing to an awesome article on
    incredible stuff we’re not used to see everyday](#link-3) - Line
    \#3’s description.

I guess this behaviour should be somewhat configurable in cmark as pandoc does with the --tab-stop parameter:

❯ pandoc ./list.md --to=markdown_github --tab-stop=2
[WARNING] Deprecated: markdown_github. Use gfm instead.
- [Link 1](#link-1) - Description of line 1.
- [Link 2](#link-2) - A very long description for the second link in the
  list. That description is more than 80 characters wide.
- [This is a very long title, pointing to an awesome article on
  incredible stuff we’re not used to see everyday](#link-3) - Line \#3’s
  description.

---

For reference, here the version of cmark I'm using, installed with brew on macOS Catalina:

❯ brew install cmark
(...)
==> Downloading https://homebrew.bintray.com/bottles/cmark-0.29.0_1.catalina.bottle.tar.gz
==> Downloading from https://akamai.bintray.com/3a/3af95418f96f4b0cec4bd76abaab312f3caf4cea591f38d3b725f15068d06491?__gda__=exp=1593691219~hmac=7f6c15036b995f36438e934f5bd44ec8
######################################################################## 100.0%
==> Pouring cmark-0.29.0_1.catalina.bottle.tar.gz
🍺  /usr/local/Cellar/cmark/0.29.0_1: 17 files, 724.9KB

❯ /System/Volumes/Data/usr/local/opt/cmark/bin/cmark --version
cmark 0.29.0 - CommonMark converter
(C) 2014-2016 John MacFarlane

[jgm]

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

[kdeldycke]

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.