Obsidian doesn't treat a paragraph (text wit blank line before and after it) as separate block

[poddex]

Hello all.
Checked all steps before posting this: no result.
Obsidian version: latest.
I don’t know what does it mean, but…
In some cases Obsidian doesn’t treat a paragraph (text wit blank line before and after it) as separate block.
Here is the gif.

Also I attached an .md file with this text.

Unnamed 2.md (438 Bytes)

Also check sandbox vault: result is the same.

It’s very annoying. Please, fix.

[vanadium]

Everything is considered to belong to the second first-level item on the top of the list. This is because right after the list, there is no empty space before the next paragraph starts.

So turn this:

		8) 6787687688
687768678768768768

into that:

		8) 6787687688

687768678768768768

and it will all work like you expect.

[poddex]

I agree, but the rule is not followed here that a paragraph is a text limited to empty lines. (as it is written in the Obsidian documentation). I see the text. which has an empty line at the top and bottom and I understand it accordingly. But Obsidian thinks that this is not the paragraph for some technical reasons of its own. Therefore, I believe that this is a bug and it needs to be fixed.

Or there is a need to make changes and warnings about exceptions in the documentation.

[vanadium]

Yes indeed. That Obsidian also includes the paragraphs, as defined by text separated by blank lines, is unexpected. Still, the single line not separated from the last bullet item is probably what the user should fix in the first place.

[poddex]

Still experience this problem. In some cases obsidian doesn’t treat paragraph as block even when I insert a blank line after last bullet. Delevopers, can you fix this? All structure is damaged because of this.

[poddex]

Look at this behavior!

Unnamed.md (423 Bytes)

Please, fix!

[ariehen]

If you switch to Reading view, you’ll notice the list continues after the 5) aaaaaaaaaa line.

The issue seems to be here:

Try changing that to a 02-02-2024, 02/02/2024, or similar. Removing the first 0 works as well: 2.02.2024.

[poddex]

But it isn’t expected! Not as described.
Paragraph must be “text with blank line before and after it”. Only this way and no other.

[poddex]

And what about this example?

unnamed2.md (213 Bytes)

Completely unpredictable behavior. Instead of focusing on the task, I have to fight with paragraphs and struggle where to insert blank lines. Is this a normal use?

[CawlinTeffid]

This looks like a bug. List markers are supposed to have a space after them, so that shouldn’t count as one. And I wouldn’t expect the leading zero to make a difference.

[ariehen]

Something is odd for sure. I was just pointing out where I think the issue starts and a workaround for now.

[Pch]

I can somewhat repro this too , I think (in the Sandbox vault):

Numbered lists seems to ignore the blank empty line after the list if the line following the blank line starts with anything that could be parsed as a number list (i.e.: 01. or 01)).

Live Preview doesn’t show it but Reading does (as pointed out by ariehen in this post here).

Here’s a small screen-recording (LP is on the left and Reading on the right) where all I do is adding and removing a . after the 01 following the blank empty line…

The raw markdown I used to test this is simply:

1. One
2. Two
3. Three

01
02
03

Now, what bothers me with this is:

1. Live Preview doesn’t render the “merging” of the items with the list above
2. Depending on the separator used between the list and 01., 01. will either be converted in Reading in a list or not

Example 1: Using a --- (with or without blank line(s) around, it doesn’t seem to matter) as separator between the list and the next 01. converts 01. in Reading solely into a numbered list

Markdown used:

1. One
2. Two
3. Three
---
01
02
03

Result: (LP on the left & Reading on the right): Same as with a simple blank line…

Example 2: Using a blank line and a markdown comment to separate the list and the following 01. doesn’t seem create a brand new numbered list … while using only a markdown comment does .

Raw markdown:

1. One
2. Two
3. Three

%% markdown comment separator %%
01
02
03

Result: 01. doesn’t get parsed as numbered list item neither in Reading nor in LP

But adding a space after 01. will render 01. as the 1st item of a numbered list in LP but not in Reading

In either cases (using a --- or %% comment %% as separator), something like 01.02.03 doesn’t seem to be interpreted as list item anymore

…but not a simple blank line

I know markdown doesn’t support line breaks (soft or hard) but I also think a blank line after a list and before what follows (regardless of “what” is) should be enough to “stop” a list …

… or at least, the rendering in LP and Reading could be more consistent maybe, so how lists works/should be written could be clearer (especially to those relying more on LP than Reading)

This has been tested in the sandbox vault with Stricts line breaks toggled Off

SYSTEM INFO:
	Obsidian version: v1.6.7
	Installer version: v1.6.5
	Operating system: Darwin Kernel Version 20.6.0: Thu Jul  6 22:12:47 PDT 2023; root:xnu-7195.141.49.702.12~1/RELEASE_X86_64 20.6.0
	Login status: logged in
	Catalyst license: supporter
	Insider build toggle: on
	Live preview: on
	Base theme: adapt to system
	Community theme: none
	Snippets enabled: 0
	Restricted mode: on

RECOMMENDATIONS:
	none

[poddex]

So, the simple tip for me that I should separate a list with blank lines before and after it, right?
And there is no way to treat a text with list in it as whole paragraph because of markdown standards, right?

[CawlinTeffid]

@Pch

I know markdown doesn’t support line breaks

It does — two or more spaces at the end of a line indicate a line break. In Commonmark (ancestor of Obsidian’s Markdown), you can use a backslash instead. Either way, in Obsidian you need to enable Settings > Editor > Strict Line Breaks for them to work. But I think they only work at the end of text lines and not on lines by themselves.

[CawlinTeffid]

I’m not fully following the discussion, but separating different things with blank lines is a good way to avoid weird behavior in Markdown.

I’m pretty sure it is valid Markdown to “interrupt” a paragraph with a list; I’m not so sure the paragraph can be continued after the end of the list.

[Pch]

@CawlinTeffid

It does — two or more spaces at the end of a line indicate a line break. In Commonmark (ancestor of Obsidian’s Markdown), you can use a backslash instead. Either way, in Obsidian you need to enable Settings > Editor > Strict Line Breaks for them to work. But I think they only work at the end of text lines and not on lines by themselves.

Yes, I misspoke … Sorry …
I remember, struggling a bit at the beginning with line breaks and simply decided to add blank line between “blocks” (whatever it is) to make sure they would appear as they should in reading (as this was before live preview came to life )

But in this case, it really seems like the line break, possibly because of the syntax used (using period as separator between the “numbers” as in 01.02.03) is silently ignored by Reading … and that simple piece of text, gets assimilated as not a new item of the preceding list but as new line (soft line break) under the last item of the preceding list…

At least, this is how I understand the indentation appearing in Reading.

But again, the “silent failing” of Live Preview (when it comes to render the final result) bothers me more than anything else here

[poddex]

I would like paragraphs and blank lines to be more predictable. I hope the developers will pay attention to this issue.

[WhiteNoise]

I checked your examples. A few things

This according to markdown is a SINGLE LOOSE list (which we intentionally do not render loose in reading mode).

- text
- text

- text
- text

you encountered this reading mode bug:

Dates (numbers with periods) get parsed as list items

In the following minimal example, the dates are displayed indented and lists are shown as loose lists while they should be tight. This is on Obsidian 1.1.9 on Windows and doesn’t seem to be a consistent bug across platforms. Numbers with periods seem to be parsed as ordered list items, even if there is no space following the period. See discussion in this thread. ## Lorem Ipsum 30.01.2023 - Lorem Ipsum - Lorem Ipsum ## Lorem Ipsum2 30.01.2023 - Lorem Ipsum - Lorem Ipsum 31.01.2023 - L…

you also encountered this reading mode bug:

Nested list rendering broken / flattened if line after is not empty

Steps to reproduce Paste the following markdown into an Obsidian file: - This is a new concept - This is nested {under} the concept - Much context is above me - Which is why this is the {case} - This is another item <!--shouldn't affect rendering--> Expected behaviour Would render like this: This is a new concept This is nested {under} the concept Much context is above me Which is why this is the {case} This is another item Actual behaviour Renders like…