Multi-line bullet points with a tag at the beginning wrongly indent after the first line in the editor mode. The following lines start from the same indentation as the bullet point, and are thus indented too little (best shown through screenshot below).
The behavior cannot be always reproduced! It might or might not show up. The only regularity I found out is, that it only happens when the line starts with a tag.
The behavior is probably related to Multiline list item indents inconsistently after first line, but instead of the problem there, it has not been solved in a previous version (as written in the thread) and also just seems to happen when there is a tag at the beginning.
Steps to reproduce
Paste the following in a note:
- Lorem ipsum dolor sit amet, consectetur adipiscing elit.
- #TODO Sed velit justo, ullamcorper ac volutpat quis, sodales molestie ipsum. Phasellus quis aliquet eros, nec euismod nulla.
- #TODO Suspendisse orci ex, euismod eu hendrerit sollicitudin, fringilla sit amet lacus.
The behavior of this is somewhat random, and might happen after pasting a list in the note, after scrolling away from the text and back, or after indenting a bullet point with TAB.
Expected result
Text on consecutive lines will start at the same position as the first line. Like in this forum:
Lorem ipsum dolor sit amet, consectetur adipiscing elit.
#TODO Sed velit justo, ullamcorper ac volutpat quis, sodales molestie ipsum. Phasellus quis aliquet eros, nec euismod nulla.
#TODO Suspendisse orci ex, euismod eu hendrerit sollicitudin, fringilla sit amet lacus.
Actual result
The line starting with sollicitudin is indented too little:
Operating system: Pop OS 22.04 (Ubuntu, more or less)
Debug info:
SYSTEM INFO:
Obsidian version: v1.1.8
Installer version: v1.0.3
Operating system: #202210290932~1669062050~22.04~d94609a SMP PREEMPT_DYNAMIC Mon N 6.0.6-76060006-generic
Login status: not logged in
Insider build toggle: off
Live preview: on
Legacy editor: off
Base theme: dark
Community theme: none
Snippets enabled: 0
Restricted mode: on
Yeah I can reproduce this too. (1.1.19, installer 1.1.19) Mostly when copy/pasting into a bullet.
(The “solved” in those other threads looks like the original posters marked WhiteNoise’s request to follow up as a solution. Which triggered the post to automatically close.)
One thing to notice, to anyone trying to test this. The text above is indented with tabs. So if you use spaces, and copy that text to test, you’ll have mixed indentation characters, which can also throw it off a little. But I can reproduce even if I switch all bullets to 4 spaces.
Furthermore, the deeper the indentation, the more the offset accumulates:
If I remove the tag and put it back, it removes the offset.
But here is a strange one. Also… if I remove the tag and put it back, it removes the offset at that indentation level, but if I use tab / shift-tab to indent or unindent, it is fixed at that original indentation level, but broken in the others.
Oh yes, I guess it appears so. But I can reproduce it easily in my vault and the Sandbox vault without going past the bullet limits.
(In that gif above I was showing a specific way that it was “fixed” only at one indentation level, after removing and replacing the tag.)
In the Sandbox vault:
make sure you turn indentation to 4 spaces. It doesn’t seem to happen with tabs. (Side note: I tried testing 8 spaces, and indenting is still only inserting 4 spaces.)
Make sure to copy enough text into the line so that it wraps. I’m just including this because the test text in OP wasn’t long enough to wrap on my screen.
(Same result for me on MacOS and Windows 10)
I just tested that technique of removing the tag and putting it back (with undo, or typing) while I’m at indentation 2. And here is the same gif. In this gif you can see the offset in 0 indentation and 1 indentation. And then at 2 indentations, it has fixed itself after deleting and replacing the tag. (Again this is what I was showing in my gif in my older post.)
