When deleting a parent list item, un-indent all of the child/subsequent nested items


New vault, no plugins, latest Obsidian desktop 1.1.16.

Bug description

Original list :


After deleting parent item “a” :

Instead of leaving the items indented, Obsidian should un-indent all of the items so that they continue to be proper lists


These sub-bullet items are now simply indented, so they become indented code blocks. In Markdown, there is no such thing as indented bullets without a parent item.

What would you expect to happen? Should they be un-indented so that they are each “top-level” bullets? If so, I can convert this to a feature request for that behaviour.

1 Like

Perhaps the outliner plugin handles this better but I am not even sure of that.

In my simple test-case reproducing this, I could select all the three lines, and hit Shift-Tab to unindent the sub-list, and everything seems to be just fine again!

Thanks for your replies :

@ryanjamurphy : Indeed, since the problem happens when editing lists, the desired outcome would be to unindent and keep the bullet formatting (while keeping the hierarchy in case of more complex lists featuring other sub-items).

@WhiteNoise : Same behavior with outliner plugin.

@holroy : Yes, for this simple example, Shift-Tab does the trick.

Converted this thread to a FR. It’d be a convenient feature!

1 Like

It probably goes without saying, but I think it would also be helpful for this behavior to occur when cutting the parent item.

I am wondering whether or not it would be more convenient to have an empty line left where the deleted parent item was in cases where the parent item was top level. In all cases for sub items, obviously the line would be removed.


Is this really wanted functionality? It would cause a lot of un-/indentations to occur when you’re reorganizing lists.

What do you foresee is happening if you move a line (within a multiple level list) up or down? Should it shift the list below to match your current level? Should it shift everything down one level? Should it try to match the level of whatever line you’re moving towards?

I think this is not a clear cut thing to implement, and that it’s not given what the result should be when a list item line is removed. It could be permanently removed, in which case shifting could be argued that it should occur. It could be a temporary move, and then something else might take its place shortly after, in which case the remaining structure should be left untouched.

In short, I think it’s better to have it like it is today. When you cut/move the line, just that line is removed. And, like today, you’re able to select and readjust the item lines below if you desire to do that. Please don’t to try to make this into one operation, as that would disturb a lot of other use cases.