obsidian-linter
obsidian-linter copied to clipboard
FR: Linting for `nested-list-spacing`
@victorzhangyf The most important change would be 4 spaces indent, right? So 2 after a number, 3 after a bullet?
Yes that's the most important change.
Could I get some more detail on this @harmtemolder or @victorzhangyf ? This sounds like a modification to the rules I have added recently for consistent styles for ordered and unordered lists. Would this only affect nested lists or is this something that would affect all lists? Either way, this sounds like it would be a spacing rule that would deal with this. I am just not sure if this applies to just nested lists or all lists.
I am not too sure how it would work on anything with content on the next line since calculating that might be difficult. However I can see it working on the line that has the list indicator on it.
@pjkaufman I agree this probably belongs to a spacing rule. For lists that are not nested, the number of spaces after the list indicator doesn't matter much as long as it's consistent. For nested lists, it's nice to have 2 spaces after ordered list indicator and 3 spaces after unordered list indicator.
Would it be possible to add a rule/setting similar to this one in the vscode markdownlint plugin? This makes the number of spaces after the list indicators configurable. I think dealing with wrapped content on the next line is a much harder problem, so perhaps can be a separate issue/feature. Thanks!
I have different idea, I think the number of spaces after the list indicator should be consistent whatever nested or not (list indicator + following spaces = 4 spaces = indent). This will make the source code looks more uniform and clear. This issue should be list space style like #485 and not just nested-list-spacing.
And I have a question, google doc doesn't make it clear, which style is right:
1. A
...
22. B
...
333.C
or
1. A
...
22. B
...
333. C
I think should be first. But how should greater than 999?
I have different idea, I think the number of spaces after the list indicator should be consistent whatever nested or not (list indicator + following spaces = 4 spaces = indent). This will make the source code looks more uniform and clear. This issue should be
list space stylelike #485 and not justnested-list-spacing.And I have a question, google doc doesn't make it clear, which style is right:
1. A ... 22. B ... 333.Cor
1. A ... 22. B ... 333. CI think should be first. But how should greater than 999?
Sorry I am not familiar with your Google Doc question.
And thanks for the clarification. I can put this in the backlog and get to it based on prioritization. Right now, bugs, performance, and a few specific features are priority. The others will come with time.
I have different idea, I think the number of spaces after the list indicator should be consistent whatever nested or not (list indicator + following spaces = 4 spaces = indent). This will make the source code looks more uniform and clear. This issue should be
list space stylelike #485 and not justnested-list-spacing.
Yes I agree -- it looks nicer (and also might easier to implement?) to keep it consistent between nested and non-nested lists.
And I have a question, google doc doesn't make it clear, which style is right:
1. A ... 22. B ... 333.Cor
1. A ... 22. B ... 333. CI think should be first. But how should greater than 999?
I'm not sure about that either. There's a formatting rule in a vscode plugin "markdownlint" that specifies the number of spaces after list markers. Because I rarely have lists longer than 10 items, that simple rule has worked for me so far.
I think Google Doc's rule is for make list mark looks uniform, make it always the same as the indent, so the source code more readable and clearly layered. So I prefer first style.
The second one looks no different from 1 space after number, it doesn't make much sense to me, 2 spaces is an added burden.
Although it's not a problem on lazy number style, and few people have long lists, but still important to consider the style of the long ascending list clearly before implementing it.