Removed excessive spaces after line prefixes for unordered lists in Markdown

[TomasLudvik]

Description

This change fixes excessive spaces after line prefixes for unordered lists in Markdown. Closes #5019.

Checklist

• I’ve added tests to confirm my change works.
• (If changing the API or CLI) I’ve documented the changes I’ve made (in the docs/ directory).
• (If the change is user-facing) I’ve added my changes to changelog_unreleased/*/XXXX.md file following changelog_unreleased/TEMPLATE.md.
• I’ve read the contributing guidelines.

✨Try the playground for this PR✨

[TomasLudvik]

Hello @fisker, what can I do to push this PR forward?

[grossmannmartin]

Hi,
this seems like a really important fix. What has to be done to push this forward?

[LucasOe]

Any progress on this? I would really like to see this feature!

[glenn-jocher]

@TomasLudvik @fisker what's the status on this PR? This is the one problem preventing Prettier adoption at our org.

[TomasLudvik]

@glenn-jocher It is waiting for review from @fisker or @sosukesuzuki as I am not a maintainer of this repo.

[grossmannmartin]

Hi @fisker, @sosukesuzuki
Any news regarding this issue?

[Lixquid]

Hi @fisker, @sosukesuzuki, I really hate to pester, but this is causing some immense grief with having to manually remove the extra spaces after the markers, is there anything anyone can do to push this forward?

The deviation fights with basically every example and other linting tool out there as shown in a comment in #5019 which makes it a near impossible sell to match the other way round.

[glenn-jocher]

@fisker @sosukesuzuki please merge this PR as soon as you can without further delay.

[beefchimi]

@fisker @sosukesuzuki another bump for getting this PR merged 🙏

[fisker]

I'm not familiar with the markdown spec, but will this break CommonMark?

[fisker]

@kachkaev mentioning you since you are involved in #3990

[kachkaev]

I'm not sure about this change TBH. If I understand it correctly, it essentially ignores tabWidth: 4 and renders lists as tabWidth: 2. Shouldn’t folks do this instead?

{
  "tabWidth": 4, // prerequisite
  "overrides": [
    {
      "files": "*.md",
      "options": {
        "tabWidth": 2
      }
    }
  ]
}

That said, I’m not certain enough to say that this PR is wrong. I’m just confused about it’s best to ignore tabWidth value rather than configure it to work as expected.

[glenn-jocher]

@fisker @kachkaev guys the #5019 bug that this PR fixes has 130 upvotes in #5019 (comment), many many users are facing problems that this PR fixes.

The basic problem is that prettier --tab-width=4 is strangely creating spaces after dashes in lists, which no one is expecting and leaves all of us unable to use prettier for formatting markdown in our projects. This PR resolves this problem correctly per my testing and operates correctly in about 300 markdown pages for Ultralytics docs.

[glenn-jocher]

@fisker @sosukesuzuki @kachkaev friendly bump to please merge this. Our 80k-star organization is pending this PR to apply prettier to all our 300 MkDocs pages, it would really help us a lot. Currently we are considering installing prettier directly from @TomasLudvik fork instead, but this is much slower, i.e. npm install --global TomasLudvik/prettier

[MartenBE]

I hope this makes it into a release soon!

It's here, and it works! Thanks everybody, real life saver this one 👍

[oliversalzburg]

The merge of this change is surprising. Maybe I'm missing something, but there is a clear distinction between:

-  A

   A

and

- B

    B

The first list item contains a text item with the text A. The second list item contains a text item with the text A. By offsetting the list item label from the list item indicator, you declare the indentation of the list item contents. Marked demo for reference.

I know you can argue about this all year around, and point to different specifications and implementations as the single source of truth, but I'm shocked to see how many people were in favor of this.

If you follow the original spec, you will find this section:

The spec also says:

List items may consist of multiple paragraphs. Each subsequent paragraph in a list item must be indented by either 4 spaces or one tab

This dictates these two options:

Prettier 3.4.0

- This is some text that is not offset from the list marker

    and now the text continues with an indent of 4

    and now the first line looks weird, doesn't it?

Prettier 3.3.1

-   This is some text that is not offset from the list marker

    and now the text continues with an indent of 4

    and now the first line looks weird, doesn't it?

Now when you use something like Prettier, you want your lists and texts to look nice. The spec literally says "To make lists look nice, you can wrap items with hanging indents". This would indicate to me that hanging indents are also the sane default for Prettier. So when I indent with 4 spaces, as is the Markdown standard, then why wouldn't my list item labels be offset from their list item markers?

I'm also not sure if the effects of proseWrap: 'always' were fully considered with this change.

[TomasLudvik]

@oliversalzburg

Here https://www.markdownguide.org/basic-syntax/#paragraphs is described your use case exactly as it prettier does now, so I think the current behavior is the correct one.

[oliversalzburg]

Here markdownguide.org/basic-syntax#paragraphs is described your use case exactly as it prettier does now, so I think the current behavior is the correct one.

markdownguide.org is an end-user tutorial, not a specification. As was explained to me in the past, Prettier follows the CommonMark spec, which specifies this behavior very clearly:

The most important thing to notice is that the position of the text after the list marker determines how much indentation is needed in subsequent blocks in the list item. If the list marker takes up two spaces of indentation, and there are three spaces between the list marker and the next character other than a space or tab, then blocks must be indented five spaces in order to fall under the list item.

This is a core Markdown behavior of how to nest HTML block elements in lists. Markdown tooling can still render this code to your expectation for your convenience, but it's still in conflict with the spec.

It is important to note that the output you receive from compiling a Markdown document to HTML is not what should decide Prettier behavior. Prettier prettifies source code, which is the Markdown document itself. If you introduce a change that modifies the semantics of the document, and then argue based on rendered output, you're misleading reviewers.

[MartenBE]

@oliversalzburg I am really confused by your explanation. First you mention the original spec that fixates 4 spaces, in the next comment you say that prettier should follow commonmark that has a different interpretation. Now the rule of commonmark seems to be to that any additional paragraphs or blocks within a list item must be indented to align with the start of the text in the first line. This is what prettier does now: it reduces the spaces, but also adjust the indentation of subsequent blocks in the list item to match that. So Prettier does seem to follow the common spec, or am I missing something?

[oliversalzburg]

@MartenBE Let me try to elaborate.

1. I bring up the original spec, which dictates 4 space indentation, because Tab width should not affect text alignment after the bullet points in Markdown lists #5019 also declares 4 spaces as the safe/sane default, and it beautifully explains the original idea behind using offsets between list item indicator and label to have more aesthetically pleasing text blocks.

2. I bring up CommonMark, not because I think Prettier should follow it, but because Prettier authors explicitly state that they follow CommonMark. This does not contradict anything that I referenced from the original spec. CommonMark and the original spec are in line when it comes to hanging indents and block child elements; at the very least within the borders of the subject at hand here.

3. When you say:

   Now the rule of commonmark seems to be to that any additional paragraphs or blocks within a list item must be indented to align with the start of the text in the first line. This is what prettier does now: it reduces the spaces, but also adjust the indentation of subsequent blocks in the list item to match that.

   I don't see how it does that, and I provided examples of that in my original comment on this thread. I'm having a hard time seeing how this would be desirable.

   

[TomasLudvik]

@oliversalzburg I have introduced this change because it solves problems for 90% of users, as many do not use paragraphs in the lists. I am sorry that it caused you some issues.

The fastest way to solve this is to find the fix for the indentation of paragraphs in the lists and create a pull request to solve this once and for all.

[oliversalzburg]

@TomasLudvik I feel like I left the wrong impression. I'm really somewhat neutral on the subject.

However, with all due respect, I doubt you have the metrics on the user base to make any assessments like "90% of users are affected", and I believe that I have clearly illustrated some aspects of Markdown and Prettier that warrant additional consideration in this context.

I'm not trying to invalidate the original requirement for this change. I just doubt that this is the correct change to satisfy the requirements while still staying within the spec.

I can see that a lot of users were frustrated about this behavior for over a year, with hardly any response from maintainers. How the threads read to me, maintainers were just tired and wanted to get this off their dashboard, without investing any time into the specifics of the issue - just like they had been for a year before finally merging this change.

I don't blame you for suggesting a change that seems obvious so that, at least, a process can get started to find the right solution. I also fully understand that, after a year of feeling ignored, you don't have the motivation to backtrack on any of this; neither would I.

This change in Prettier brought up code style violations in pretty much all of my JavaScript projects, but I don't care about reformatting all my README.md files in all my projects.

I also maintain projects that parse Markdown and interpret the semantic blocks in the AST to generate new information. That's the only reason why my attention moved here. This change in Prettier introduces document transformations that are not compliant with the spec that Prettier aims to support. This makes 100% of the documents produced by Prettier liable to be non-compliant to the spec, which overrules your 90% 😉

I wish I could offer an olive branch to find some middle ground for certain cases where the "excessive spaces" could actually be removed, but I'm having a hard time seeing how the implementation complexity and implicit unreliable behavior would actually be a benefit to users.

I'm also having a hard time even understanding the original requirements. All of them are purely personal interpretation of esthetics. The only real requirement is that "it would make markdownlint happy". markdownlint is highly opinionated and even explains directly in its README that the default rules are probably wrong for you. If you're not even customizing your markdownlint rule set, based on the recommendations of the author, why would Prettier need to change?

Again, I'm not trying to invalidate that users feel a pain, I just don't understand their situation fully. When I read through the original threads, everybody who complains is saying things like:

It's the only thing preventing us from using Prettier for Markdown.

Okay. Why? What is your real problem that requires us to make Prettier non-compliant with CommonMark?

[CHC383]

Okay. Why? What is your real problem that requires us to make Prettier non-compliant with CommonMark?

@oliversalzburg Just my 2 cents. A lots of the users come to this PR because of #5019, personally I don't know which of the following complies with the specs, but intuitively I like the 2nd case because it would be the same as I write the markdown manually (only typing one space after the list marker).

With tab width 4

Before this PR

-   Item
    -   Subitem
    -   Subitem
-   Item
    -   Subitem
    -   Subitem

After this PR

- Item
  - Subitem
  - Subitem
- Item
  - Subitem
  - Subitem

In the 2nd case, the tab width doesn't affect the spaces after the list markers.

The discussions above are mainly around the subsequent paragraph

• Before the PR, the indention of the subsequent paragraph matches the spaces after the list markers for tab widths 1 to 5, and mismatch when it is > 5.
• After the PR, the alignment mismatch for tab widths > 2.

Maybe some of the users, especially the ones come from #5019 (like me), didn't realize the impact of subsequent paragraph, and mainly voted for the issue and this PR because of the spacing after the list markers. Personally, I don't know too much about the spec, and only care if the prettier output looks nice to me, and if the render HTML looks as expected. In some of my projects with tab width set to 4 (for markdown and source code), this PR fix the looking issue, for the other projects with tab width 2, with or without this PR is the same, although using tab width 2 might already be non-compliant with the markdown spec.

I just want to share the original problem and the feeling of an end user, and maybe there is a middle ground to make prettier compliant with the specs, as well as making the users like me happy about the spaces after the list marker. Or maybe the requirements of #5019 doesn't compliant with the specs at all when the tab width is 4, then it has to be a trade off, meet the spec or make the users happy.

[oliversalzburg]

@CHC383 Thank you for the clear reflection of a user's original mindset that brings up this requirement. I really do appreciate it.

Right out of the gate, I have to agree that the after example looks dramatically more aesthetically pleasing than the first one. There is no argument about this from my point of view. But given the wide variety of Markdown documents I've seen on GitHub alone, this is not a realistic example that illustrates the issue fully.

Now, if you were using an indent of 2 spaces in your configuration, we wouldn't even have this argument, right? Because then you would have had the after result even before the change. So why is 4 spaces even a subject, if 2 spaces provides a more suitable result already?

We have to remember that when Markdown was thought up, it recognized tabs as an equal option to spaces in the indentation mechanics. I don't want to go to into the thinking behind that, but I hope one example illustrates the core issue here.

Prettier and IDE set to 2 Space Indent

1. This is an ordered list item
  1. This is the first item in a nested, ordered list

Here, I have started an ordered list and pressed Return at the end of the first line. I then pressed Tab to indent the next line. This inserted 2 spaces, based on my own configuration.

The result is not a nested list; it's two list siblings:

1. This is an ordered list item
2. This is the first item in a nested, ordered list

Prettier and IDE set to 2 Space Indent - How Users fix it

There are 2 common approaches users use to resolve this:

3 Space Indent Fix

1. This is an ordered list item
   1. This is the first item in a nested, ordered list

Some users like to insert the missing space (manually or automatically), which aligns the layout with the spec. As long as you don't introduce 2-digit list item prefixes, you have no problems with this solution. Users who prefer this solution also commonly like to not declare the position of their list items explicitly. Instead of using 8., 9., 10., ..., they just use 1. for all items. As long as you have a numeric prefix, it will be an ordered list item, which have their position implicitly declared through the DOM representation. However, you must not ignore that there are users and documents out there that prefer explicit position declaration.

Once you hit 2-digit indices, the layout of the Markdown source and the rendered result become inconsistent and unpleasant.

9. Ordered list item
   1. Nested list item
11. Ordered list item
   1. Nested list item

renders as

9. Ordered list item
   1. Nested list item
10. Ordered list item
11. Nested list item

Prettier and IDE set to 4 Space Indent

And this is exactly why the safe default is 4 spaces. This gives you plenty of room for list indices that go up to 99.

1. This is an ordered list item
    1. This is the first item in a nested, ordered list

Here, I have started an ordered list and pressed Return at the end of the first line. I then pressed Tab to indent the next line. This inserted 4 spaces, based on my own configuration.

The result is a nested list, as was my intention. However, the Markdown looks somewhat less pleasing than with the 3 space indent. Also, this is basically abusing the fact that the single space before the new ordered list block element is ignored when the Markdown is rendered. From a parser's point of view there is, and always was, a space in front of the nested, ordered list - unless I would add another space after the 1. on the first line.

Why is this person talking about ordered lists, when this is about unordered lists?

Unordered lists obviously have the benefit that their list item indicator never changes in length; it's always * or -. I believe that's what makes the issue so frustrating for most users, because the underlying patterns are non-obvious here.

Ultimately, it doesn't matter which type of list you are nesting inside the list element. The semantics that dictate the space between the list item indicator and its label are the same.

Quick Reminder

If a sequence of lines Ls constitute a sequence of blocks Bs starting with a character other than a space or tab, and M is a list marker of width W followed by 1 ≤ N ≤ 4 spaces of indentation, then the result of prepending M and the following spaces to the first line of Ls, and indenting subsequent lines of Ls by W + N spaces, is a list item with Bs as its contents. The type of the list item (bullet or ordered) is determined by the type of its list marker. If the list item is ordered, then it is also assigned a start number, based on the ordered list marker.

Code Blocks

I know that we all love to use triple-backtick "code fences" or whatever you want to call them today. But Markdown dictates support for purely indent-indicated code blocks. If you look at the original spec, you'll see that 4 spaces, or 1 tab, also indicate a code block. CommonMark also still fully recognizes indent-based code blocks (check out example 109).

Now try to combine the concepts of indent-indicated code blocks with indent-indicated list item nesting. This is one of the biggest challenges in Markdown since the original spec.

The OP in #5019 explicitly stated:

I know that nested lists are one of the trickiest parts of Markdown so maybe I'm missing some non-obvious reason why list texts are aligned the way they are.

Yes, @borekb, this is non-obvious if there ever was something non-obvious.

I find this very hard to tie together, but I hope this playground helps to illustrate it.

When you carefully examine this, you will hopefully see confusing inconsistencies. If you modify the spacing between list item indicators, and the list item label, you will also see how the interpretation of the nested code blocks changes.

Remember, a nested list block does not suffer from invalid list item Markdown syntax, because excessive spaces have no effect on the block. But when you declare a nested code block through indentation, then every single space becomes relevant. You can see this when you render the Prettier output from the above playground to HTML- code blocks easily have every single line prefixed by a single space.

So what's the Solution?

Sorry for taking so many words to say "You're wrong. Get over it.". What you are seeing is a fragment of applying Markdown/CommonMark correctly. Ultimately, Markdown is a language to describe HTML. While we want a beautiful Markdown document when we apply Prettier, we also want that document to follow patterns that reflect robust best practices.

If what you are aiming for only looks good as long as you have only a single line on each list item, and you never expect anyone to want to use indent-based code blocks, that's fine, but maybe that's not a great sane default for a tool as widely used as Prettier.

I feel like the authors of Prettier originally understood this and that's why we had the original implementation. The introduced change is a regression due to miscommunication and maintainer fatigue.

[benutzer193]

One reason for using 4 spaces is that some implementation require 4 spaces for nested list items, see e.g. Python-Markdown/markdown#451 (this library is also used by mkdocs).

[MartenBE]

The fastest way to solve this is to find the fix for the indentation of paragraphs in the lists and create a pull request to solve this once and for all.

We can discuss all we want here, but I think this is the way forward. The unit tests of prettier didn't catch this, so then it must be included. Best indeed to create a PR to fix it and discuss it there.

[Alexander-Shukaev]

We have indent_size = 4 and after this change we get:

--   [About](#about)
--   [Help](#help)
--   [Build](#build)
-    -   [Library](#library)
-    -   [Examples](#examples)
-    -   [Tests](#tests)
--   [Test](#test)
-    -   [Build and Run](#build-and-run)
-    -   [Run (Only)](#run-only)
+- [About](#about)
+- [Help](#help)
+- [Build](#build)
+    - [Library](#library)
+    - [Examples](#examples)
+    - [Tests](#tests)

this conflicts with https://github.com/markdownlint/markdownlint/blob/main/docs/RULES.md#md007---unordered-list-indentation

MD007:
  indent: 4
  start_indented: false
  start_indent: 4
  
MD030:
  ul_single: 3
  ol_single: 2
  ul_multi: 3
  ol_multi: 2

The idea of 4-sized indents is that the list (either numbered or unordered) starts at first position and has 3 more characters (needed for numbered lists when they run into teens, e.g. 12. ), this leads to nice alignment of both list styles. Current change makes it inconsistent and conflicting. Please make this new behavior configurable if you want to keep it.

[MartenBE]

@Alexander-Shukaev The link you gave points further to https://cirosantilli.com/markdown-style-guide/#spaces-before-list-marker for 4 space indents, which actually advises the prettier corrected output for one line items in unordered lists:

If the content of every item of the list is fits in a single paragraph, use 1 space.

For the other case (multiparagraph), there was already some discussion, but there is need for someone to step up and create a PR that handles both this case and the paragraphs in lists as said in #15526 (comment)

[Alexander-Shukaev]

@MartenBE, my point is solely that the style, for which I gave my rationale and we relied upon, is now broken by a hard-coded change. I personally find that advice about single-line items highly debatable and the damage done by the current change far worse for the general case than the "benefit" of having inconsistent style for one-liners, however nobody has to agree with me and that's fine (as that's what we have configuration options for). As it currently stands, this PR is disruptive and low-quality change and, with all the respect, it should be considered for a revert to be instead fixed properly in future for all cases (but without disruptions to existing consistent 4-space style). I disabled Prettier for Markdown in our organization until then (or forever).

[oliversalzburg]

@MartenBE

We can discuss all we want here, but I think this is the way forward. The unit tests of prettier didn't catch this, so then it must be included. Best indeed to create a PR to fix it and discuss it there.

Note that this change only changes a single line of business code, and makes 270 changes to test code to make the change pass.

A statement like, "unit tests of prettier didn't catch this" is completely misplaced in this thread IMHO.

[oliversalzburg]

@Alexander-Shukaev

this conflicts with markdownlint/markdownlint@main/docs/RULES.md#md007---unordered-list-indentation

Such a statement is borderline insane, given that markdownlint explicitly states that it is extremely opinionated, and you most likely need your own rules. Like, it's right there directly on the front page README of the tool. Why are you even referencing this?

[oliversalzburg]

The only thing that has become clear, since I started to contribute to this thread, is how useless of a tool Prettier actually is today. We argue here about a core aspect of the tool, with zero maintainers in sight. And they are the ones who accepted this completely invalid change in the first place.

Prettier is a joke. If you forced it to work your way now, I'm happy for you. But the times where it was a sane default tool is over.

I'm still happy to use the last working versions and am very grateful for all the work of all the contributors that made that version possible. But there is no fun in following the development further

[MartenBE]

@MartenBE

We can discuss all we want here, but I think this is the way forward. The unit tests of prettier didn't catch this, so then it must be included. Best indeed to create a PR to fix it and discuss it there.

Note that this change only changes a single line of business code, and makes 270 changes to test code to make the change pass.

A statement like, "unit tests of prettier didn't catch this" is completely misplaced in this thread IMHO.

I meant that this implies that we should add unit/integration tests to see if the formatting still generates the same HTML with commonmark.js, to prevent this incertainty in the future.

If I have some time, I think this is a cool experiment:

1. Get the markdown from the unittests from before this PR got merged and put it in the commonmark.js dingus for the HTML.
2. Do the same for the edited tests after the merge.
3. Check if they are the same

If the generated HTML output is the same by the commonmark.js library, this whole discussion is moot. If there are differences, then it forms a nice base for a new PR.
I think this is a more constructive and fact-based path forward, because now this discussion is getting emotional and going nowhere, causing most people to unsubscribe from the thread (I can't blame them as I am considering the same) instead of searching for a solution.

[MartenBE]

So, I found some time and did the test as described in my previous comment in light to put this discussion back on things we can objectively measure. I compared the outputs of the existing tests from v3.3.3 and v3.4.2 by these files as these are the only edited test files in the PR according to https://github.com/prettier/prettier/pull/15526/files#diff-983b3030349454a8de0fac39f7936183afd84febe286948e2f26c7bf5500ba13:

• v3.3.3: https://github.com/prettier/prettier/blob/52829385bcc4d785e58ae2602c0b098a643523c9/tests/format/markdown/list/__snapshots__/format.test.js.snap
• v3.4.2: https://github.com/prettier/prettier/blob/cca946176c3ec04ae46bf7bcb08c5bba8c041682/tests/format/markdown/list/__snapshots__/format.test.js.snap

Where the outputs where different (thus edited in the PR), I put those outputs through the CommonMark Dingus ( https://spec.commonmark.org/dingus/ ) to convert to HTML and then diffed the outputted HTML snippets to see if there are any structural differences between v3.3.3 and v3.4.2.

These are the results:

• No difference at all in CommonMark HTML: 13 tests

  • exports[align.md - {"proseWrap":"always","tabWidth":4} format 1]
  • exports[codeblock.md - {"proseWrap":"always","tabWidth":4} format 1]
  • exports[combined-lists.md - {"proseWrap":"always","tabWidth":4} format 1]
  • exports[interrupt.md - {"proseWrap":"always","tabWidth":4} format 1]
  • exports[issue-7846.md - {"proseWrap":"always","tabWidth":4} format 1]
  • exports[long-paragraph.md - {"proseWrap":"always","tabWidth":4} format 1]
  • exports[loose.md - {"proseWrap":"always","tabWidth":4} format 1]
  • exports[multiline.md - {"proseWrap":"always","tabWidth":4} format 1]
  • exports[nested.md - {"proseWrap":"always","tabWidth":4} format 1]
  • exports[nested-tab.md - {"proseWrap":"always","tabWidth":4} format 1]
  • exports[separate.md - {"proseWrap":"always","tabWidth":4} format 1]
  • exports[simple.md - {"proseWrap":"always","tabWidth":4} format 1]
  • exports[tab.md - {"proseWrap":"always","tabWidth":4} format 1]

• No structural differences in CommonMark HTML (only wrapping on different location): 3 tests

  • exports[checkbox.md - {"proseWrap":"always","tabWidth":4} format 1]
  • exports[indent.md - {"proseWrap":"always","tabWidth":4} format 1]
  • exports[nested-checkbox.md - {"proseWrap":"always","tabWidth":4} format 1]

• Structural differences in CommonMark HTML: 0 tests

16 unit tests where edited in this PR. And, it seems that the only difference is the word wrapping, which is logical as some spaces are omitted due to this PR (- -> - ) and thus allowing some words back on the line. Otherwise there aren't any structural differences in the HTML output between v3.3.3 and v3.4.2 according to the CommonMark parser.

So I think we can conclude that according to the unit tests, this PR didn't include any structural breaking changes according to the CommonMark norm. If something still isn't right, new tests and fixes should be added like we said before by creating a new issue or PR.

[MartenBE]

The idea of 4-sized indents is that the list (either numbered or unordered) starts at first position and has 3 more characters (needed for numbered lists when they run into teens, e.g. 12. ), this leads to nice alignment of both list styles. Current change makes it inconsistent and conflicting. Please make this new behavior configurable if you want to keep it.

@Alexander-Shukaev I found this PR ( #4281 ), which I think could be very useful in your use case and also be more future proof (aligning lists with 100+ items etc.). Perhaps it is best to revive that PR as it is still open and labeled needs discussion.

[kareldonk]

Holy shit, who thought that this breaking change was a good idea?

Using prettier 3.3.3:

Here is a test list:

-   Lorem Ipsum is simply dummy text of the printing and typesetting industry.
    Lorem Ipsum has been the industry's standard dummy text ever since the 1500s,
    when an unknown printer took a galley of type and scrambled it to make a type
    specimen book. It has survived not only five centuries, but also the leap into
    electronic typesetting, remaining essentially unchanged. It was popularised in
    the 1960s with the release of Letraset sheets containing Lorem Ipsum passages,
    and more recently with desktop publishing software like Aldus PageMaker
    including versions of Lorem Ipsum.

    It is a long established fact that a reader will be distracted by the readable
    content of a page when looking at its layout. The point of using Lorem Ipsum
    is that it has a more-or-less normal distribution of letters, as opposed to
    using 'Content here, content here', making it look like readable English. Many
    desktop publishing packages and web page editors now use Lorem Ipsum as their
    default model text, and a search for 'lorem ipsum' will uncover many web sites
    still in their infancy. Various versions have evolved over the years,
    sometimes by accident, sometimes on purpose (injected humour and the like).

-   Lorem Ipsum is simply dummy text of the printing and typesetting industry.
    Lorem Ipsum has been the industry's standard dummy text ever since the 1500s,
    when an unknown printer took a galley of type and scrambled it to make a type
    specimen book. It has survived not only five centuries, but also the leap into
    electronic typesetting, remaining essentially unchanged. It was popularised in
    the 1960s with the release of Letraset sheets containing Lorem Ipsum passages,
    and more recently with desktop publishing software like Aldus PageMaker
    including versions of Lorem Ipsum.

Using prettier 3.4.0:

Here is a test list:

- Lorem Ipsum is simply dummy text of the printing and typesetting industry.
  Lorem Ipsum has been the industry's standard dummy text ever since the 1500s,
  when an unknown printer took a galley of type and scrambled it to make a type
  specimen book. It has survived not only five centuries, but also the leap into
  electronic typesetting, remaining essentially unchanged. It was popularised in
  the 1960s with the release of Letraset sheets containing Lorem Ipsum passages,
  and more recently with desktop publishing software like Aldus PageMaker
  including versions of Lorem Ipsum.

    It is a long established fact that a reader will be distracted by the readable
    content of a page when looking at its layout. The point of using Lorem Ipsum
    is that it has a more-or-less normal distribution of letters, as opposed to
    using 'Content here, content here', making it look like readable English. Many
    desktop publishing packages and web page editors now use Lorem Ipsum as their
    default model text, and a search for 'lorem ipsum' will uncover many web sites
    still in their infancy. Various versions have evolved over the years,
    sometimes by accident, sometimes on purpose (injected humour and the like).

- Lorem Ipsum is simply dummy text of the printing and typesetting industry.
  Lorem Ipsum has been the industry's standard dummy text ever since the 1500s,
  when an unknown printer took a galley of type and scrambled it to make a type
  specimen book. It has survived not only five centuries, but also the leap into
  electronic typesetting, remaining essentially unchanged. It was popularised in
  the 1960s with the release of Letraset sheets containing Lorem Ipsum passages,
  and more recently with desktop publishing software like Aldus PageMaker
  including versions of Lorem Ipsum.

Note the second paragraph in the first list item using more spaces for indentation when using prettier 3.4.0.
The same thing happens if you include a code block in a paragraph; it gets more spaces and the whole list gets out of alignment. Also this is inconsistent with numbered lists.

Wen fix?

[MartenBE]

CommonMark wise they output the same HTML, but I agree the latter is nicer to look at. The conondrum is that the indent of It is... is logical as the tab width is 4. This PR fixes a lot of nuissances with non-multiple-paragraph-list, but it's painpoint is indeed when using multiple paragraphs as discussed earlier in this thread. This PR solves the issue for people that didnt't want prettier to change their -. into -... as this messes up lists with singe paragraph lists, in this case (multiple paragraphs) we would prefer the latter ... .

Perhaps it would be best to let prettier see what you do in the first entry and just apply that to the rest of the list, that way everybody could be happy. Let's discuss this further in your issue at #16929 .

[marcospgp]

does anyone know how long until this surfaces in the vscode prettier extension?

[CHC383]

does anyone know how long until this surfaces in the vscode prettier extension?

See https://github.com/prettier/prettier-vscode?tab=readme-ov-file#prettier-resolution, the extension uses the version you installed. This is in Prettier 3.4.0