Edit:
- this post summarizes multiple issues. Read the posts below↓ to understand them more easily one by one.
Context:
Steps to reproduce
Described in screenshot or in source text attached in section “Additional information”
Expected result
- Pairing ^block-id like with list item on the same indentation level, like closing brace in “one true brace style”.
- ^block-id separated by one empty line refers to whole list on the same indentation level as is now.
- Presence of block-id should not influence resulting indentation (reported flattening of nested lists)
Actual result
Environment
- Operating system: Windows 7
- Obsidian version: from introduction of block references through current 0.9.17
- Indenting done by tabs, not spaces
Additional information
source text:
⚑201103_0010. ▷201103.
- ∈ [[AbadoS]] since 2020-11-03.
- subject: issues with block-referencing nested lists
original list:
- 1
- 1.1
- 1.2
- 1.2.1
- 1.2.2.1
- 1.2.2
^id1
- **affixed id flattens indentation of nested list, also in embeddings**
```
- 1 // copy in code block
- 1.1
- 1.2
- 1.2.1
- 1.2.2.1
- 1.2.2
^id1
```
- 1 transcluded by `![[#^id1]]`:
- ![[#^id1]]
newlines to align with rendered preview for screenshot
- 2
- 2.1
- 2.2
- 2.2.1
- 2.2.2.1
- 2.2.2
^id2-2
- **refering to sublist works although with above mentioned flattening of involved sublevels**
```
- 2 // copy in code block
- 2.1
- 2.2
- 2.2.1
- 2.2.2.1
- 2.2.2
^id2-2
```
- 2.2 transcluded by `![[#^id2-2]]`:
- ![[#^id2-2]]
newlines to align with rendered preview for screenshot
- 3
- 3.1
- 3.2
- 3.2.1
- 3.2.2.1
- 3.2.2
^id3-2
^id3
- **refering to list and sublist at the same time fails, i.e. transcludes whole page. **
```
- 3 // copy in code block
- 3.1
- 3.2
- 3.2.1
- 3.2.2.1
- 3.2.2
^id3-2
^id3
```
- 3 transcluded by `![[#^id3]]`:
- ![[#^id3]]
- 3.2 transcluded by `![[#^id3-2]]`:
- ![[#^id3-2]]
keywords: indentation, list, nested block reference
This bug report is quite dense. But I am not conviced there is any bug here.
we clearly say that
To refer to complex blocks like tables, put the block ID on its own after the block, and make sure there is an empty line both before and after the block ID.
Which it doesn’t look like you are doing in any of your examples.
1 Like
Let me try to separate issues and explain them in more consumable pieces. In the post above, I sticked with illustrations without empty lines because refering to indented sub-tree failed completely when (correspondingly indented) block-ID was surrounded by empty lines, as I illustrate in next post of this explanatory sequence.
Refering to whole list** according to WhiteNoise↑ works as expected, i.e.:
^block-id separated by one empty line involves [refers to] whole list on the same indentation level as is now.
… as I said in original report above.
Linking to a sub-list is possible (at least unofficially yet) by avoiding empty line before “^block-id”.
Current interpretation of scope by Obsidian for ^block-id is convenient and intuitive.
If linking to a sub-list required surrounding empty lines, then it would be ambiguous whether we link to whole list or just one item with it’s sub-tree. (Aside of taking three times more space on screen in edit mode.)
Issue: affixed ^block-id without surrounding empty lines flattens indentation of nested list in preview mode, also in embeddings.
source text: (if needed to reproduce)
original list:
- 0
- 1
- 1.1
- 1.2 indentation lost
- 1.2.1 in preview
- 1.2.2.1 and in embed
- 1.2.2
^id1
^id0
**Refering to whole list** according to [WhiteNoise↑](https://forum.obsidian.md/t/issues-with-block-referencing-nested-lists/9108/2) **works as expected**, i.e.:
> `^block-id` separated by one empty line involves whole list on the same indentation level as is now.
... as I said in original report [above](https://forum.obsidian.md/t/issues-with-block-referencing-nested-lists/9108/1).
- Whole list transcluded by `![[#^id0]]`:
- ![[#^id0]]
**Linking to sublist is possible (at least unofficially yet) by avoiding empty line before "^id1". But affixed `^id` flattens indentation of nested list in preview mode, also in embeddings:**
```
- 0 // copy of list in code block
- 1
- 1.1
- 1.2 indentation lost
- 1.2.1 in preview
- 1.2.2.1 and in embed
- 1.2.2
^id1
^id0
```
- sublist "1" transcluded by `![[#^id1]]`:
- ![[#^id1]]
**Current interpretation of scope by Obsidian for `^id` is convenient and intuitive.**
**If linking to a sublist required empty line before, then it would be ambiguous whether we link to whole list or just item "1" with it's subtree. **
(Aside of taking three times more space on screen in edit mode.)
Surrounding indented ^id by empty lines fails, i.e. transcludes whole page. Whether or not surrounding empty lines contain any indentation.
But if it worked, I would rather prefer it to transclude the sub-list on the same indentation level (without the header item), just like it does now for whole list without indentation.
source text: (if needed to reproduce)
original list 3:
- 2
- 3
- 3.1
- 3.2
- 3.2.1
- 3.2.2.1
- 3.2.2
^id3-2
**Surrounding indented `^id` by empty lines fails, i.e. transcludes whole page. Whether or not surrounding empty lines contain any indentation. **
```
- 2 // copy in code block
- 3
- 3.1
- 3.2
- 3.2.1
- 3.2.2.1
- 3.2.2
^id3-2
```
**But if it worked, I would rather prefer it to transclude whole list on the same indentation level, without the header item, just like it does now without indentation.**
i.e. `^id3-2` would also transclude "3.1". Illustration of expected result with indented ^id3-2 surrounded by empty lines:
```
- 3.1
- 3.2
- 3.2.1
- 3.2.2.1
- 3.2.2
```
- result of transclusion by `![[#^id3-2]]`:
- ![[#^id3-2]]
Refering to indented sublist works by indenting ^id like “one true brace style”. But with added ^id, the indentation of involved sublevels does not propagate to preview.
source text: (if needed to reproduce)
original list 2:
- 1
- 2 // original list has nested indentation
- 2.1
- 2.2
- 2.2.1
- 2.2.2.1 // indentation lost in preview and embedding
- 2.2.2
^id2-2
- **Refering to indented sublist works by indenting `^id` like "one true brace style". But with added `^id`, the indentation of involved sublevels does not propagate to preview.**
```
- 1 // copy in code block
- 2 // original list has nested indentation
- 2.1
- 2.2
- 2.2.1
- 2.2.2.1 // indentation lost in preview and embedding
- 2.2.2
^id2-2
```
- indented sublist "2.2" transcluded by `![[#^id2-2]]`:
- ![[#^id2-2]]
This is the last post of the sequence.
Refering to two sub-lists at the same time fails, i.e. transcludes whole page.
source text: (if needed to reproduce)
⚑201127_1333. ▷201127.
- ⊂ [[201103_0010]] since 2020-11-27.
original list:
- 2
- 3
- 3.1
- 3.2
- 3.2.1
- 3.2.2.1 indentation lost in preview
- 3.2.2
^id3-2
^id3
**Refering to two sublists at the same time fails, i.e. transcludes whole page. **
```
- 2 // copy in code block
- 3
- 3.1
- 3.2
- 3.2.1
- 3.2.2.1 indentation lost in preview
- 3.2.2
^id3-2
^id3
```
- sublist "3" transcluded by `![[#^id3]]`:
- ![[#^id3]]
- indented "3.2" transcluded by `![[#^id3-2]]`:
- ![[#^id3-2]]
Maybe this is the source of the misunderstanding.
Let me clarify:
We don’t support sub-list blockid linking
You can search\open a feature request.
The format is this and only this at the moment
- a
- b ^lineid
- c
- d
^listid
other text
1 Like
Thank you @WhiteNoise for clarification, I did not know it almost works just by accident instead of intended support. Here is my feature request with proposed syntax to specify the scope of block-id:
Is this ^listid different from blockid?
I was thinking about referencing a group of bullet points is more useful than referencing them individually as block (which they are considered by obsidian) and stumbled on this thread by accident.
@Archie It is the same. Markdown lists are converted to html lists <ol> or <ul> which belong to html block elements. Lists as blocks can contain other blocks (list items). And I want block ID syntax that works in these nested scenarios with markdown’s elegance/conciseness.
2 Likes
I came here because I even expected sublists to be included into block references to a list item - precisely because of your argument: sublists are html block elements in a list item. Consequently, I do not just think the feature is desirable, I also think it would be far more consistent with the concept of a “block reference” as it is at the moment. Furthermore, I think for anyone who includes outliner elements into their workflow the current behaviour is seriously limiting. All in all, I would very much welcome a change in behaviour here.
2 Likes
