FR: empty line around lists

[berot3]

Describe the Solution You'd Like

Linter has already the following "emtpy line around"-formatings implemented:

1. Blockquotes
2. Code fences
3. Math Blocks
4. Tables

I see that this are all some lind of blocks, but still I think it makes a lot of sense to also add Lists.

By Lists I mean both, ordered and unordered.

original text
1. step 1
2. step 2

expected outcome:

original text

1. step 1
2. step 2

Additional Context

If you write markdown in obsidian and do not leava a empty line between a line of text and the list, the reading-view will add that line autmatically. So to make markdown editor and reader closer, I personally always add a line before the list. And thats where linter would come into play :)

Thanks for reading and considering!

[berot3]

Alternative: Right now I use this other plugin that supports it already: https://github.com/alexgavrusev/obsidian-format-with-prettier

[zedtools]

I second this.

This can partially be achieved by enabling Paragraph blank lines, but for some reason there is no blank between the end of the list and a paragraph following the list. For example:

Paragraph before list.

- List item 1
- List item 2
Paragraph after list.

I'm not sure if this is a bug in the Paragraph blank lines functionality, or whether a list needs a similar option to have a blank link added after it.

[berot3]

so is there a chance this can be implemented? :)

[zedtools]

I noticed with my sample markdown:

Paragraph before list.

- List item 1
- List item 2
Paragraph after list.

that Obsidian indents "Paragraph after list." to line up with the list items when in Reading mode. I'm not sure if this is expected behaviour, as I cannot see it documented anywhere. Indenting "Paragraph after list." with a Tab or two spaces also does the same thing.

Introducing blank lines at the end of a list may break this if anyone is using it as a feature. I'd be happy to add a blank line, unless the paragraph immediately after the list is indented with spaces or tabs.

[pjkaufman]

Hey @berot3 , @zedtools . Thanks for reaching out and providing information around this. This feature is something that can be added to the Linter, but right now there are a couple of scenarios that would need to be looked into more/be ironed out to make sure there is a clear understanding of how to address this issue. Admittedly, that is something I, or another dev will have to do for some of these things. But here are a couple of them.

What is the expected way to handle nested lists? Are they considered to be a part of the same list or would the blank lines apply to them as well? I assume they are to be treated as the same list, but I know that they are treated a little differently by the parser so they would have to be handled in a special way.

What is the expectation around a list of checkboxes right after a regular list (this might be more of an AST/parser question)? Do we consider those two lists to be one or are they separate?

What is the expectation when dealing with nested blockquotes where the blockquotes are side by side (this is an edge case I would like to understand what the expected behavior of is)?

For example, what is expected if we have the following content:

> Content here
> > - List item 1
> > - List item 2
>
> > - Another list item 1
More content here...

Would those two nested blockquotes get joined in this scenario? Or is the expectation that they would stay separate? Right now, I believe the logic is setup to join these two blockquotes since I believe that different blockqoutes at the same level should be separated with something more than an empty line/blockquote.

Thanks for the help on better understanding some of these things!

[pjkaufman]

It is already looking like there may be some difficulties from a technical standpoint since the AST parser considers the following to be a single list after a paragraph (see ast parser results here):

Paragraph before list.
- List item 1
- List item 2
Paragraph after list.  
more test here

So that will make things tricky because the same kind of thing is true for other text as well. So in order for this to work, the parser will have to consider all list items that end in two spaces,
.
, or \ and a new line a continuation of a list item and anything that does not follow those conventions as a break in the contents of the list item. This could break things, but this is the best I can think up at this time.

[pjkaufman]

Currently there is a very basic implementation of this that does need to have the ability to determine if a list item is truly a continuation of the table or if something else is going on. So that will need to be dealt with, but hopefully it will not be too bad. But that is all I have time for today.