Editor: Incorrect detection of number list with offset number but without blank line

[WhiteNoise]

There is a little special case of markdown numbered (ordered) lists that Obsidian does not handle correctly

# Case 1 (it's a list)

Text  

1. item one  
2. item two 

# Case 2 (it's a list)

Text  
1. item one  
2. item two 

# Case 3 (it's a list)

Text  

3. item one  
4. item two 

# Case 4 (it's not a list)

Text  
3. item one  
4. item two  

According to CommonMark, Case 1, 2, 3 are ordered lists. Case 4 is NOT. Editor/Live Preview does not handle this. Reading mode does.

[ClareMacrae]

Once you’ve done the above, delete everything above this line.

Steps to reproduce

1. Open the Sandbox vault
2. Create a new file
3. Paste in this content:

1. [ ] #task Task 1 in 'numbered_list_items_standard'
    1. Sub-item 1
2. [ ] #task Task 2 in 'numbered_list_items_standard'
    2. Sub-item 2
3. List item in 'numbered_list_items_standard' 

1. Open the file in 3 panes, side-by-side:
   • Source mode
   • Live Preview
   • Reading mode
2. Compare the visual rendering of all 5 lines across the 3 panes

Did you follow the troubleshooting guide? [Y]

Expected result

All 5 lines are rendered in all 3 panes as follows:

1. A root-level checkbox
2. An indented list item
3. A root-level checkbox
4. An indented list item
5. An root-level list item

Actual result

tl;dr CachedMetadata.listItems for this file has only 4 items, not the expected 5 - it is missing the list item on line 4. This breaks Reading-mode rendering, and task plugins that use the cache.

Lines are rendered like this - the bold text shows the difference, on line 4:

1. A root-level checkbox
2. An indented list item
3. A root-level checkbox
4. as plain text with leading spaces
5. An root-level list item

Caption: Above: Screenshot with side-by-side comparison of Source Mode, Live Preview and Reading Mode rendering of the sample text. Only the Reading Mode version is rendered incorrectly.

Environment

SYSTEM INFO:
	Obsidian version: v1.8.9
	Installer version: v1.8.9
	Operating system: Darwin Kernel Version 24.1.0: Thu Nov 14 18:15:21 PST 2024; root:xnu-11215.41.3~13/RELEASE_ARM64_T6041 24.1.0
	Login status: logged in
	Language: en
	Catalyst license: vip
	Insider build toggle: on
	Live preview: on
	Base theme: adapt to system
	Community theme: none
	Snippets enabled: 0
	Restricted mode: off
	Plugins installed: 0
	Plugins enabled: 0

RECOMMENDATIONS:
	none

---

Additional information

How I found this

I discovered this when writing automated Tests for the Tasks plugin: I found that the CachedMetadata.listItems for this file has only 4 items, not the expected 5.

Not the same issue

This looks similar to this, but it is about the wrong number being rendered, whereas this is about a numbered list item not even being recognised as a list item:

• Broken numbered nested lists in version 1.8.9

Workaround

There is a workaround, like this:

1. [ ] #task Task 1 in 'numbered_list_items_standard'
    1. Sub-item 1
2. [ ] #task Task 2 in 'numbered_list_items_standard'
-    2. Sub-item 2
+    1. Sub-item 2
1. List item in 'numbered_list_items_standard' 

File with workaround:

1. [ ] #task Task 1 in 'numbered_list_items_standard'
    1. Sub-item 1
2. [ ] #task Task 2 in 'numbered_list_items_standard'
    1. Sub-item 2
3. List item in 'numbered_list_items_standard' 

Caption: Above: If the prefix on Sub-item 2 is changed to 1., then Obsidian renders the line correctly as a list item.

What other tools say

WebStorm renders 2. Sub-item 2 fine:

Caption: Above: WebStorm manages to renders the original line correctly as a list item.

StackEdit agrees with Obsidian:

Caption: Above: Website stackedit.io has the same error as Obsidian’s Reading Mode.

And requires the same workaround as Obsidian to display Sub-item 2 consistently:

Caption: Above: Website stackedit.io requires the same workaround as Obsidian’s Reading Mode.

[ClareMacrae]

Here’s a different way of seeing the behaviour…

Markdown for this demo:

1. Item
    1. Sub-item 2
    2. Sub-item 3
    3. Sub-item 4

| Pane        | Mode         |
| ----------- | ------------ |
| Left pane   | Source mode  |
| Middle pane | Live Preview |
| Right pane  | Reading mode |

Steps:

• Change the list-item number of the first Sub-item from 1, to 2
• Then back to 1
• And keep an eye on the difference between Live Preview and Reading Mode rendering

[dawni]

I believe you’re encountering this:

Editor: Incorrect detection of number list with offset number but without blank line

There is a little special case of markdown numbered (ordered) lists that Obsidian does not handle correctly # Case 1 (it's a list) Text 1. item one 2. item two # Case 2 (it's a list) Text 1. item one 2. item two # Case 3 (it's a list) Text 3. item one 4. item two # Case 4 (it's not a list) Text 3. item one 4. item two According to CommonMark, Case 1, 2, 3 are ordered lists. Case 4 is NOT. Editor/Live Preview does not handle this. Reading mode does.

Here’s how I came across it: Ordered lists: Each nested level must start with "1" to be understood as a new list item.

My general workaround is to add a blank line before the sub-item so Obsidian will interpret it as a list item and not just a continuation of the previous line (which was a different list item).

So like:

1. [ ] #task Task 1 in 'numbered_list_items_standard'
    1. Sub-item 1
2. [ ] #task Task 2 in 'numbered_list_items_standard'

	2. Sub-item 2
3. List item in 'numbered_list_items_standard'

It’s not pretty but it works: