Double empty line in markdown lists changes marker

[kachkaev]

Looks like two or more empty lines between both list items in markdown work as a flipper for the marker. * toggles to - and 1. toggles to 1) 🤷‍♀️

Prettier 1.12.1

• Playground link - unordered list with *
• Playground link - unordered list with -
• Playground link - ordered list with 1. 2. 3.
• Playground link - ordered list with 1) 2) 3)
• Playground link - ordered list with 1. 1. 1.
• Playground link - ordered list with 1) 1) 1)

Input:

* hello1

* hello2


* hello3

* hello4


* hello5

* hello6

Output:

* hello1

* hello2

- hello3

- hello4

* hello5

* hello6

Marker style does not fix itself even after the second format.

Expected behavior:

* hello1

* hello2

* hello3

* hello4

* hello5

* hello6

[ikatyang]

Opened remarkjs/remark#332.

[kachkaev]

Thanks @ikatyang for opening an upstream issue. Even though remark gets three lists instead of one, what causes the markers to flip? I thought this would be the printer's job, which is a part of prettier.

[ikatyang]

See http://spec.commonmark.org/0.28/#example-264.

[kachkaev]

Not sure I'm right, but IMHO prettier could just merge consequent lists and the problem would be solved. In which situations would this cause a regression?

I also guess there is a chance that remark is right about producing several lists in that scenario.

[ikatyang]

Their ASTs are different and it'll cause rendered HTML to be different especially if CSS applied, for example:

* hello1
* hello2
- hello3
- hello4
* hello5
* hello6

• hello1
• hello2

• hello3
• hello4

• hello5
• hello6

[kachkaev]

To be honest, it's hard for me to imagine a scenario when someone wants to have two lists of the same kind following each other. It's much more common that there's an extra blank line after a listing etc. inside a list item, which unexpectedly splits up the list. I have been facing this several times already and had to manually go through 1) → 1. in diffs after running Prettier.

[ikatyang]

There's no marker kind in the AST, all we know in prettier is that remark told us there're three separate lists, so we cannot fix this issue without upstream fixes.

Currently remark produces the same AST for the following two cases:

* hello1
* hello2


* hello3
* hello4

* hello1
* hello2
- hello3
- hello4

[kachkaev]

Yeah, I understand that there are two lists in the AST. What I'm wondering is if these lists could be ‘merged’ during printing. This would require a change in getPrefix(), which currently looks like this:

prettier/src/language-markdown/printer-markdown.js

Lines 251 to 261 in 1f84880

	function getPrefix() {
	const rawPrefix = node.ordered
	? (index === 0
	? node.start
	: isGitDiffFriendlyOrderedList
	? 1
	: node.start + index) +
	(nthSiblingIndex % 2 === 0 ? ". " : ") ")
	: nthSiblingIndex % 2 === 0
	? "* "
	: "- ";

E.g. roughly to this:

          function getPrefix() {
            const rawPrefix = node.ordered
              ? (index === 0
                  ? node.start
                  : isGitDiffFriendlyOrderedList
                    ? 1
                    : node.start + index) + "."
              : "*";

(isGitDiffFriendlyOrderedList would just have to apply to the fist list in a sequence)

This change would not allow for two consequent lists to be rendered in the output. I know that those are supported by the spec, but I'm not sure if they are being used at all in practice. Accidental insertion of a double \n\n in a single list is way more common (at least, according to my own experience).

[kachkaev]

What I'm trying to say is that Prettier could have its own opinion when it comes to consequent lists of a single kind. It can just merge all such lists into a single one and thus better work for cases like:

* hello1

* hello2

- hello3

- hello4

* hello5

* hello6

(I see this list as a single list, it's just not prettified)

It's probably fine that remark detects separate lists when there's too much white space between item. there is a chance that some users of that library consider this as a correct behavior.

[ikatyang]

We can't merge them even if it's less used, the 1st goal for a formatter is to be correct, people won't trust a formatter that'll change the meaning of the code for any reason.

I believe this issue should be fixed in remark since the root cause is that it didn't follow the CommonMark spec in this case.

[joealden]

Any movement on this problem? I am still experiencing this issue on the latest version of prettier (1.19.1) even though I can see that the "problem" was fixed upstream (remarkjs/remark#332).