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'm not familiar with the markdown spec, but will this break CommonMark?

@fisker Actually, this PR makes prettier closer to what Commonmark shows in its tutorials: see #5019 (comment) . @kachkaev , this PR in fact works together with tabwidth instead of a replacement. The indent is handled by tabwidth, but the spaces behind the marker should be handled independent of this as that is not an indentation (see comment above by @glenn-jocher ).

[glenn-jocher]

@fisker friendly nudge here to please merge this PR when you can, thank you!

[aarongustafson]

@sosukesuzuki Looks like it’s awaiting your approval as well. Any updates / thoughts?

[GitMurf]

Really looking forward to this update! I have been banging my head against the wall why my markdown lists were being formatted so wonky and this appears to be the reason. Thanks in advance!

[grossmannmartin]

Friendly reminder of the existence of this PR @sosukesuzuki

[MartenBE]

I hate to be that guy, as I greatly respect open source contributors and their time and work/life balance, but the PR is kindly provided by @TomasLudvik almost a year ago and is only waiting for just a single review from @sosukesuzuki for quite some time. Is there any way we can push this PR forward? Looking at how many issues in other projects this has created (see them linked in this PR and its issue #5019 ), the fact it has already passed one of two required reviews from @fisker , has included tests and passes all the checks, ... it is just kinda sitting here for almost a year which is unfortunate. It would be a waste to see it go stale: is there anything we can do to help?

[kachkaev]

@fisker shall we get this one in? We can tweak the internals later if there is feedback from @sosukesuzuki.

[glenn-jocher]

Would make my life a lot simpler with this merged!

I currently run prettier and then a custom script to revert the changes to what this PR does.

[mr-codr]

I love you

[theoludwig]

Thank you! 😄

[TomasLudvik]

Thank you!!! 😄

[aarongustafson]

🥳

Thank you so much!

[jace]

I hope this makes it into a release soon!