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

(Playground)

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

Most upvoted comments

I’d be just as happy with an opt-out, as would all the other supporters of this issue

Actually I wouldn’t. This is a bug. There’s no way on earth that this output is correct:

-   Item
    1. First Subitem
    2. Second Subitem
-   Item
    -   Subitem
    -   Subitem
-   Item

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:

- Item
  - nested

and just change the top-level to ordered list:

1. Item
  - nested

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:

-   Item
    -   nested

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.

prettier-formatting

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.

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:

{
  "tabWidth": 2,
  "overrides": [
    {
      "files": "*.md",
      "options": {
        "tabWidth": 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:

  • There may be 1–4 spaces between the list marker and its content (see the Basic case list item in this section). No specific size in that range is recommended and it is not explicitly correlated with indent size.
  • All of the examples showing correct formatting for nested lists use 1 space after the marker, even though they use different amounts of indentation up to the list markers themselves. You can see these starting at Example 264 (2 space). Also see 266 (4 space), 267 (3 space), 268 & 269 (nested on one line), and 270 (list containing headings as the first child of list items).
  • Example 256 Demonstrates that indentation within a list item is measured from the first non-space character after the list marker, regardless of the number of spaces between the list marker and that first non-space character.

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:

  • Empty list items, which should have no trailing spaces.
  • List items that start with an indented code block, as shown in Example 243. But actually, this isn’t an exception – the code block should be indented 5 spaces: 1 to separate the list marker from its content and 4 to represent the indented code block.

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

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

This results in the following

<!-- Before Prettier -->
- item
  - sub
  - sub
- item
  - sub
  - sub
<!-- After Prettier -->
-   item
    -   sub
    -   sub
-   item
    -   sub
    -   sub

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…

<!-- Before Prettier -->
1. item
   - sub
   - sub
2. item
   - sub
   - sub
<!-- After Prettier -->
1. item
    - sub
    - sub
2. item

    - sub
    - sub

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:

11. 123
12. 123

… being considered “aligned”, but:

1. 123
2. 123

… not.

Also, there appear to be bugs with ordered lists as well, even with 2-space indentation:

1. a
    1. b
    2.     c

->

1.  a
    1.  b
    2.      c

… why the spaces in front of a and b? 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 )