prettier: Tab width should not affect text alignment after the bullet points in Markdown lists
This is a nested list as given in CommonMark tutorial:
* Item
1. First Subitem
2. Second Subitem
* Item
- Subitem
- Subitem
* Item
It is formatted like this with --tab-width=4
(four is a safer value than two):
- Item
1. First Subitem
2. Second Subitem
- Item
- Subitem
- Subitem
- Item
I expected this output (just *
replaced with -
):
- Item
1. First Subitem
2. Second Subitem
- Item
- Subitem
- Subitem
- Item
Reasoning:
- It’s the natural form in which nested lists are written.
- I believe it would be less work for Prettier.
- It is similarly easy to look at. There will be personal preferences here but I don’t think Prettier generally worries about beautification too much, as long as the code is “correct” (whatever that means in Markdown), reasonably formatted and consistent with common practices.
- It feels illogical to me to apply
--tab-width
both before and after the bullet, also, there is an internal inconsistency when setting tab width greater than 5 as you can see in--tab-width=5
vs.--tab-width=6
. - As a small bonus, the new formatting would be compatible with markdownlint.
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. If that was a purely aesthetic decision, I wanted to create this issue as a counter-argument as I believe simplicity and consistency are generally preferred in Prettier over attempts at beautification.
(As a side note, I ran Prettier over hundreds of Markdown files in our repo and it did a great job overall, better than I expected. That is admirable with virtually zero config options. 👍)
About this issue
- Original URL
- State: open
- Created 6 years ago
- Reactions: 128
- Comments: 33 (5 by maintainers)
Commits related to this issue
- feat: use 2 tab width for md until https://github.com/prettier/prettier/issues/5019 is fixed — committed to foray1010/common-presets by foray1010 5 years ago
- feat: use 2 tab width for md until https://github.com/prettier/prettier/issues/5019 is fixed — committed to foray1010/common-presets by foray1010 5 years ago
- feat: Add editor configuration Fixes nested Markdown lists, but triggers <https://github.com/prettier/prettier/issues/5019>. Hopefully that's fixed soon. — committed to linz/geostore by l0b0 2 years ago
- feat: Add editor configuration (#1630) Fixes nested Markdown lists, but triggers <https://github.com/prettier/prettier/issues/5019>. Hopefully that's fixed soon. — committed to linz/geostore by l0b0 2 years ago
- Prettier: Fix configuration The issue is that in markdown files, bullet points are arranged in a weird way. https://github.com/prettier/prettier/issues/5019 — committed to jwpconsulting/projectify-frontend by justuswilhelm a year ago
- Prettier: Fix configuration The issue is that in markdown files, bullet points are arranged in a weird way. https://github.com/prettier/prettier/issues/5019 — committed to jwpconsulting/projectify-frontend by justuswilhelm a year ago
- Prettier: Fix configuration The issue is that in markdown files, bullet points are arranged in a weird way. https://github.com/prettier/prettier/issues/5019 — committed to jwpconsulting/projectify-frontend by justuswilhelm a year ago
- Prettier: Fix configuration The issue is that in markdown files, bullet points are arranged in a weird way. https://github.com/prettier/prettier/issues/5019 — committed to jwpconsulting/projectify-frontend by justuswilhelm a year ago
- Override markdown tabwidth for prettier formatting workaround for https://github.com/prettier/prettier/issues/5019 — committed to CCBR/CCBR_NextflowTemplate by kelly-sovacool a year ago
Actually I wouldn’t. This is a bug. There’s no way on earth that this output is correct:
I have created a fix for this issue at https://github.com/prettier/prettier/pull/15526
This should be closed since it’s not a bug and I find the current behaviour the best compromise right now. See #3990 for context.
I’m setting up Markdown formatting & linting for a project after a while and have the following observations related to this:
I tried going with the default 2-space indentation but it really doesn’t work well in practice, for example, when I have this unordered nested list:
and just change the top-level to ordered list:
it breaks (I would have to also add one space before the nested bullet).
Four spaces are much easier to work with in an editor but also unfortunately, lead to a bad formatting by Prettier due to this issue. The example above would be formatted as:
which is a bit ugly and also makes markdownlint unhappy.
I don’t think this has a good solution until Prettier’s behavior is changed so for now, we’ll have to omit it from our workflow around Markdown files.
Hello, I have the same problem with @borekb. My Vscode is ver.1.35.1 and Prettier is ver.1.9.0.
Whether its bug or not, the current functionality makes very little sense at all.
Came across this bug today, any updates on a fix?
@borekb you can make tab width = 2 in your markdown files while everything else uses 4:
Forcing markdown tab width to be 2 will create unnecesssry diffs for those who have been usfing 4 already.
@ikatyang I think your example is already well-formatted (Prettier would just replace
*
with-
). I may be missing why “alignment detection” is necessary in the first place.I don’t think this relates to vscode. I use prettier either directly via the CLI command in a git hook or with a vim plugin. The behavior is from prettier, so it doesn’t matter what integration you use for it.
Here are a few things I gathered from the spec:
From what I can see, it’s not incorrect to add more than one space after the list marker (as Prettier currently does for 3-4 space indents), but it is a break from the most common convention within their docs (and what I’ve seen anecdotally) of using one space. The current behavior also conflates indentation with the spacing after the list marker, which the spec does not imply, to my understanding. I’m in support of consistently using exactly one space between a list marker and its first child, regardless of
--tab-width
, with only 2 exceptions:https://github.com/foray1010/common-presets/commit/77f951bcc35489513923e85067d07c1ba9871e64 works well but this really should be fixed.
I just stumbled into this bug myself. We are migrating from Bitbucket Server which supports CommonMark to Bitbucket Cloud which uses Python-Markdown. Our sub list items were rendering incorrectly after the migration because Python-Markdown requires four spaces to create nested list items and we had just been using two.
I figured we could use prettier to reformat this for us cleanly so I modified my prettier configuration like so
This results in the following
As others have noted there is extra padding between the bullet and the content that is unexpected. This does not seem to happen with order listed of when unordered sub list items are part of an ordered list…
Note also that the extra line introduced after
2. item
despite the input specifying a tight list.@ikatyang,
Are you able to fix this? It’s the only thing preventing us from using Prettier for Markdown. 😞
I could try updating
isAligned
to handle unordered lists similarly to ordered lists, but I really don’t understand the logic, like:… being considered “aligned”, but:
… not.
Also, there appear to be bugs with ordered lists as well, even with 2-space indentation:
->
… why the spaces in front of
a
andb
? Why is there 4-space indentation?Is there any update on this? Top hit websites for markdown show the requested formatting (4 indent spaces, single space between marker and list item) as examples. E.g.
It is weird that prettier deviates from these examples. It also really fights with markdownlint ( https://github.com/DavidAnson/markdownlint/blob/main/doc/Prettier.md )