It would be nice to have the numbers in numbered lists adjust automatically when there are line additions, removal, or swapping.
This is similar to this issue, which has been promoted to the bug graveyard.
Nevertheless, the numbering does NOT update in Edit mode when a middle item is deleted, as described in issue 404. It IS updated in Preview mode.
Is there a way to get it to update in Edit mode too because it is confusing in Edit mode to see a discontinuous number series?
Switched from help to bug reports as I don’t think this is on the user side.
Thanks. I 1st thought it was my issue, so started typing in the Help section. Then, before posting I checked and found the other issue, and forgot to switch to the Bug section. Sorry.
I’ve noticed this as well. Not a huge deal but it would be nice if both modes updated to the correct number.
We strongly recommend you to search the forum with possible keywords before submitting a new bug report. Please also try your repro steps with third-party plugins and custom CSS disabled and see if it’s still reproducible. If it’s an issue with third-party plugins or themes, try contacting the author for help. Once you’ve done the above, delete this line.
type a list with 4 item
then delete the third index content 3.xx
the left side index is same as right side
- Operating system: win10
- Obsidian version: 0.9.20
+1 for this bug report.
It’s annoying… esp. when you have a numbered list with many items, updating the correct number (in edit mode) is really a huge project.
During the correction, if you press the enter key by accident, a new numbered item is insert, and numbers in the rest of the list will automatically +1 again.
I found a way to trigger the re-ordering of the numbered list, which can be a workaround:
One can insert a sub item under the 2-nd item, and the items in parental list which is after the 2nd item will be re-ordered automatically.
@GLight: the issue is about deleting an item.
I think the issue is that the action of deleting does not trigger the expected update of the number of the items in the list in the edit mode.
What I posted is a workaround which can trigger the update of the number in the list. With this workaround, we can wait for the developers to enhance the Obsidian without getting our noting experience affected too much by this issue.
@GLight: your workaround is for adding an item to a list. But if one deletes an item, is there a workaround so it updates?
After some more tests, I found the real trigger is the tab key. You can always trigger the update whenever you want(e.g. after deleting an item): directly pressing the tab key to trigger the re-numbering of the current item and the items below which are with the same indent level:
NOTE: The items above the insertion are not affected.
NOTE: The child items are not affected.
btw, you may need to delete the inserted tab key after the update.
Would it be feasible to automatically trigger the renumbering whenever inserting or deleting a line in a numbered list?
(as pointed out by @GLight the functionality already exists, but it needs to be manually invoked by hitting tab).
There are many bug reports/comments/requests to improve re-numbering in lists.
- Create a new note. Set view to Editing Mode.
1. first. Then press Enter.
- Move cursor to end of first line and press Enter.
- Type anything.
The numbered list to update with the correct numbering sequence:
Editing Mode should match Reading Mode.
Duplicate numbers appear in the list in editing mode:
Reading mode shows the correct numbering sequence:
- Operating system: Windows
- Debug info:
Obsidian version: v0.13.14
Installer version: v0.12.19
Login status: logged in
Catalyst license: none
Insider build toggle: off
Live preview: on
Legacy editor: off
Base theme: dark
Community theme: none
Snippets enabled: 0
Safe mode: on
+1 for this feature request. Especially with live preview ordered lists should re-order when items are changed. Users generally expect lists to re-number when edited (And I remember when Ulysses had the same problem. It took a few years for it to be fixed).
I’m also interested in this feature.
This actually works, to some extent, now:
But it doesn’t work if you use move line up or down. In that case the list ends up with the wrong numbers.