Obsidian repeatedly wrongly changes user entered numerals in numeric lists

Obsidian fails to honor user-entered numbers for numeric lists. For example, with this list, if I add a newline after item 3, it will be changed to a 1. In fact while typing item 3, it will be changed to 1 AFTER EVERY CHARACTER I TYPE. Obsidian repeatedly thinks it “knows better” than the user, repeatedly introducing the same error OVER AND OVER.


1. When you explain the problem to your family, do they understand you?
   - [ ] Yes 
   - [ ] No
2. When you explain the problem to friends, do they understand you?
   - [ ] Yes 
   - [ ] No
3. Does the problem exist in more than one industry?

What should happen? Obsidian SHOULD NEVER OVERWRITE THE NUMBERS ENTERED BY THE USER! If I want to start (or continue!) my list with number 3, that’s my business. There is never a single circumstance where the number I just typed on the line should be replace. All legitimate times to change a number involve me making a change on another line. For example, if I delete line 1, then the numbers for lines 2 and 3 should change. But no change on line 3 should cause the number on line 3 to change.

1. When you explain the problem to your family, do they understand you?
2. When you explain the problem to friends, do they understand you?
3. Does the problem exist in more than one industry?

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

Steps to reproduce

Paste the markdown at the top into Obsidian. Go to line 3. Add a newline.

Did you follow the troubleshooting guide? [Y/N]

YES!

Expected result

I expected to NOT HAVE MY TEXT MODIFIED AGAINST MY WILL AND AGAINST ALL LOGIC!

Actual result

The number was repeatedly changed to 1.

Environment

SYSTEM INFO:
	Obsidian version: v1.10.6
	Installer version: v1.8.4
	Operating system: Darwin Kernel Version 24.6.0: Mon Jul 14 11:30:34 PDT 2025; root:xnu-11417.140.69~1/RELEASE_ARM64_T8103 24.6.0
	Login status: not logged in
	Language: en
	Insider build toggle: off
	Live preview: on
	Base theme: adapt to system
	Community theme: Blue Topaz v2025071401
	Snippets enabled: 0
	Restricted mode: off
	Plugins installed: 2
	Plugins enabled: 2
		1: BRAT v1.4.0
		2: Interweave v1.0.3

RECOMMENDATIONS:
	Custom theme and snippets: for cosmetic issues, please first try updating your theme and disabling your snippets. If still not fixed, please try to make the issue happen in the Sandbox Vault or disable community theme and snippets.
	Community plugins: for bugs, please first try updating all your plugins to latest. If still not fixed, please try to make the issue happen in the Sandbox Vault or disable community plugins.


Additional information

Nope.

You have a typo. You only have 3 spaces before your indented list. See the X in my Markdown below. If you change it to 4, it seemingly works fine.

1. When you explain the problem to your family, do they understand you?
XXX- [ ] Yes 
   - [ ] No
2. When you explain the problem to friends, do they understand you?
   - [ ] Yes 
   - [ ] No
1. Does the problem exist in more than one industry?
2. 

---

1. When you explain the problem to your family, do they understand you?
XXXX- [ ] Yes 
    - [ ] No
2. When you explain the problem to friends, do they understand you?
    - [ ] Yes 
    - [ ] No
3. Does the problem exist in more than one industry?
4. 

That is the number of spaces created by ⇧↩, so it’s not my typo, it’s a bug in Obsidian.

(But that is useful information—that if I correct the spacing issue Obsidian created then I can get the correct behavior from it. So thank you!)

Ok cool, I’m not trying to blame you. But you are currently in possession of the notes containing a typo. So let’s try to figure it out?

There might be a bug. But let’s investigate why you’re getting 3 spaces on tab. That is not default behavior for Obsidian/CommonMark. I’m on MacOS too.

You said you went through the troubleshooting steps but your “Show debug info” is still showing a theme, old installer, and a BRAT plugin.

In the Sandbox vault do you still get 3 spaces when hitting tab?

Did you change the Settings → Editor → Indent visual width? I think that is just a display, but to be safe, double check that it is set to “4”.

That’s all I can think of for the moment.

I didn’t enter :right_arrow_curving_left: and then ⇥. I entered ⇧:right_arrow_curving_left:. So ⇥ is not really relevant to this.

EDIT:
Discourse is displaying the characters above wrongly (except when editing). I didn’t enter a return and then a tab. I entered shift+return, so tab isn’t really relevant to this problem.

So in the Sandbox vault do you still get 3 spaces when hitting shift return?

I can confirm that this is a bug. While the Markdown used for the task list might be invalid, the list numbering should not be getting modified in this case. I will investigate further.

1 Like

If I’m not mistaken, the three spaces follows the Markdown (and presumably CommonMark) spec because the line under a numbered list item must line up with the first text after the number and period and space.

However 4 spaces is arguably what Markdown SHOULD have specified. (I say “arguably” since it’s clearly a debatable topic.) So my guess is that the person implementing one Obsidian feature followed the spec, and the person implementing another Obsidian feature did what seemed to make more sense within the context of an editor where the spaces are not visible and therefore where the Markdown spec seems to make no sense.

Have you found anything out in your investigations?

Obsidian already diverges from the spec(s) in a lot of ways, and I don’t want to add to them, but I think accepting BOTH a fixed number (like 4) AND whatever number lines up the text properly (3 in this case with 1-digit numbers, 4 if the numbers have 2 digits, 5 if the numbers have 3 digits, etc.) would actually INCREASE compatibility rather than decrease it.

Yes, as far as I remember. I’m 95% certain the answer is “yes”.

My earlier message (of a few minutes ago) was a reply to you. I don’t know why Discourse lost the connection. I’m sending this in case that’s the only way you get a notification of a reply.

I am sorry we had an internal discussion about this report a while back.

Let me update you on this:

First

Shift-enter is to continue writing at the current level in the hierarchy. Using shift enter to nest is wrong. You need to use enter-tab

Second,
We currently only support 1 tab or 4 spaces for indentation.

The actual Commonmark spec that determines when something is indented is quite complex, 1 tab/4 spaces is a crude approximation. For that you can continue here:

1 Like