Support sub-list embedding

malecjan · November 27, 2020, 8:20pm

Use case or problem

I want to link/embed nested list which is indented part of another list.
Refering to nested sublists now works only by accident and with issues

Issues with block-referencing nested lists - #7 by WhiteNoise

Proposed solution

Edit 2021-06-22:

This feature request might be also solved by more flexible/general / complementary request Support for Linking To/Embedding Ranges
It uses less concise syntax, due to need to specify both starting and ending ID. Due to this property it will also be more obvious what the scope of the reference is, even from raw source code. No need to locate link target and see if id follows empty line.
But the main reason for preferring syntax for ranges is potential to solve many other use-cases and feature requests. For example we can transclude any part of the nested list instead of whole sublist.
Then the syntax suggested here might be partially redundant.

Example list: 
- 0
- 1
	- 1.1
	- 1.2
		- 1.2.1 ^id1-2-1
			- 1.2.2.1
		- 1.2.2
	^id1-2
- 2
	- 2.1
	- 2.2
		- 2.2.1
			- 2.2.2.1
		- 2.2.2
	
	^id2-0
^id2

^id0

Expected results:

^id0 is preceded by empty line.
![[#^id2-0]] transcludes whole list and is already officially supported.
^id1-2 is indented and is not preceded by empty line.
![[#^id1-2]] should transclude preceding item on the same indentation level including enclosed sub-tree, like “one true brace style”:

- 1.2
	- 1.2.1
		- 1.2.2.1
	- 1.2.2

^id1-2-1 is preceded by whitespace and is appended at the end of line with some content, not only the whitespace.
![[#^id1-2-1]] transcludes - 1.2.1 and is already officially supported.
^id2 is not preceded by empty line but immediately follows nested list.
![[#^id2]] should transclude preceding item on the same indentation level including enclosed sub-tree, like “one true brace style”:

- 2
	- 2.1
	- 2.2
		- 2.2.1
			- 2.2.2.1
		- 2.2.2

^id2-0 is indented and preceded by empty line.
![[#^id2-0]] should transclude sub-list on the same indentation level similarly to current syntax for transcluding whole list:

- 2.1
- 2.2
	- 2.2.1
		- 2.2.2.1
	- 2.2.2

Relevant discussions

Related feature requests

keywords: attribute, encapsulated, embedding, fine-grained addressing, focus, ID, identifier, hierarchy, narrow down, nested, outliner, range, scope, sub-block, sub-list, zoom in

I-d-as · November 27, 2020, 10:58pm

Good idea. If I am following correctly, would this solution make it possible to make a block of just one indentation level in a list? Like the opposite of the following but as as a reference:

I mean, I know your proposed solution does more for sub lists than I asked about above, but I am curious, because that would be cool. Thanks.

malecjan · November 28, 2020, 12:54am

If I understand you correctly, then Hotkeys for “Fold one more level” and “Unfold one more level” would be useful.

My proposal can be used to focus on sub-list by transcluding it somewhere. Then we might want editable embeds.

This proposal merely extends set of referable elements (blocks) from current flat / single level block sequence to hierarchy of nested elements.
It identifies continuous portion of content, having start point and end point.
In html they are demarkated by paired tags (opening tag and closing tag) and identified by “id” attribute.
In proposed markup,
end point is marked by string in form “^block-id” satisfying certain properties.
Start point is not marked by any additional string but instead is matched according to whitespace (newlines, indentation) surrounding “^block-id” and according to syntax for nested list.

@I-d-as This does not filter any valid content like Sub-lists, they are preserved in the block.

Things that are removed in preview/embedding, are:

part of the indentation which common for all non-empty lines in the “block”.
html comments
block-ids
…

I-d-as · November 28, 2020, 3:55am

Gotcha. Thanks. I think this was a case where my interpretation was biased by what I wanted to see.

It is still a very good idea and implementation. Thanks for the detailed response and clarification.

bishop1860 · November 28, 2020, 10:36am

+1 to this. Block embeds at any level would be a great feature. However, I think these indented IDs would make the list hard to read in edit mode AND automatic generation of such links would be harder to implement

- list item
    - child 1
        - sub-child1
    ^child-1-id
    - child 2

Maybe it should just rely on the current block id, that’s already implemented:

- list item
    - child 1 ^child-1-id
        - sub-child1
    - child 2

So if we want to embed just child 1, we would use this syntax: ![[note#^child-1-id]]
And if we want to embed child 1 with all its sub-items, we would just use a different kind of link, like !![[note#^child-1-id]] or !>[[note#^child-1-id]]

manunamz · May 30, 2021, 2:24pm

Background

Obsidian currently supports file, header, and block/bullet level link embeds. This is great!

Some current behavioral details:

Header level link embeds show all content until either the next header of the same level or the end of the file is reached.
Block level link embeds show the content of the linked block/bullet.

Use case or problem

Sometimes I want to see header level link behavior for blocks. For example, with a file of this format:

# Heading
- Spec 1
    - Detail A
    - Detail B
    - Detail C
- Spec 2
.
.
.

I might want to embed all the content from Spec 1, but I don’t want it to be rendered as a heading.

Proposed solution

Add the ability to choose the preview/embed style – either just the current line as blocks currently work or the entire “subtree” as headers currently work.

This could potentially be accomplished by adding a single character to specify “full tree”. It could be a double !!, for example: !![[filename#^block_id]].

It would be doubly neat if syntax maintains uniform usage with the behavior of heading links. (So, perhaps reversing the syntax above so the double !! does the single-block embed and single ! does the entire subtree embed as headers do.)

So, in the end, usable syntax might be:

Entire subtree: ![[filename#^block_subtree]]
Block-only Link: !![[filename#^block_txt_only]].

I have also requested this behavior for Dendron

Related feature requests

Add Ranges To Header-Level Embeds

manunamz · June 16, 2021, 6:29pm

For block subtree embeds you can move the blockID to the bottom of the tree range:

- first point
    - second point
    - third point
^blockID

Originally from: Embedding headings respects hierarchy - #4 by derekvan

Related bug : This requires breaking lists if you only want to embed a section of a list:

// This will link the block correctly, but will render the list with extra spaces.
- first point
    - second point
    - third point
^blockID
- fourth point

(Not filling out a real bug report because I suspect this is not a supported/advertised feature)

WhiteNoise · June 22, 2021, 8:14pm

I personally find the notation

- Spec 1
    - Detail A
    - Detail B
    - Detail C
    ^sublistid
- Spec 2
- Spec 3

Ugly and probably hard to digest for other markdown editors.

I have been thinking of something like

- Spec 1 ^id
    - Detail A
    - Detail B
    - Detail C
- Spec 2
- Spec 3

with
![[note#^id]] for single bullet embed
![[note#*id]] for sublist embed

malecjan · June 22, 2021, 9:33pm

@WhiteNoise what do you think about the case with indented block id preceded by empty line?:

- Spec 1
    - Detail A
    - Detail B
    - Detail C

    ^sublistid
- Spec 2
- Spec 3

Expected result: ![[note#^sublistid]] transcludes only the sublist:

- Detail A
- Detail B
- Detail C

This will allow to cut/paste and indent/unindent lists together with their ID without breaking references.

- Detail A
- Detail B
- Detail C

^sublistid

Lack of this ability makes maintenance (reorganization) of referenced lists awkward/impossible.

Need for new syntax ![[note#*id]] would not be so urgent then.

WhiteNoise · June 22, 2021, 10:09pm

For refactoring, both notations have pros and cons. Depending on what you are trying to do.

I do not like sublistid after the list because at best this will trigger other editors to interpret the list as loose and at worse they won’t parse it properly. We’ll see. I’ll keep following the convo.

malecjan · June 23, 2021, 11:16am

To me, syntax [[note#*id]] seems elegant but inconsistent with existing syntax for top-level lists.

- Spec 1 ^id1
    - Detail A ^ida
       - Detail a1
    - Detail B
    - Detail C ^idc
- Spec 2
- Spec 3 ^id3

Currently existing syntax for block id at line-end together with proposed syntax for ranges would not be most efficient but would allow to do everything needed:

![[note#^id1..idc]] or ![[note#^id1..^idc]] would transclude

- Spec 1
	 - Detail A
		 - Detail a1
	 - Detail B
	 - Detail C

and both ![[note#-^id1..^idc]] and ![[note#^ida..^idc]] would transclude only sublist
```
 - Detail A
	 - Detail a1
 - Detail B
 - Detail C
```
![[note#^id1..^id3]] would transclude whole top level list without need for current syntax with blank line and id after list (which makes refactoring currently infeasible).

harold · December 19, 2021, 6:36pm

can be expect this soon?

balOS · December 19, 2021, 9:04pm

also running into this quite frequently now. painful to have to stop using an outline structure if i want to embed.

would be great to have support added in a future update!

GLight · January 5, 2022, 2:06am

Use case or problem

The list is hierarchical. When a list item contains sub-bullets, it means that each of these sub-bullet items has a strong tie to the parent list item. And in most of the case the sub-bullet items belong to the parent list item from some aspects.

Based on this understanding, a reference to the parent list item should, in-explicitly, have taken all the sub-bullets of the parent list item into account.

in note-a, there is a list:

# A subject
## People
bla

bla

## Lectures
bla

bla

## Books
- books being mentioned
    - book-set-a ^bookseta
        - book-a
        - book-b
        - book-c
    - book-set-b ^booksetb
        - book-e
        - book-f
        - book-g
    - book-set-c ^booksetc
        - book-h
        - book-i
        - book-j
- books not mentioned
    - book-k

in note-b, there is block references to the book-sets

The following books are available:

![[note-a^bookseta]]

![[note-a^booksetc]]

And the following books are unavailable:

![[note-a^booksetb]]

in note-b, a block reference which shows only “book-set-a” or “book-set-b” or “book-set-c” is almost useless. What is expected in note-b is the names of the book within the specified book-set, in the form of a expandable list:

Jan-05-2022 09-41-15

Since we have already grouped books into different sets with a list in note-a, it is not necessary to give a separate block reference to each of the books within the book-sets in note-a and use them separately in note-b.

Proposed solution

It is better that the sub-bullets items are also shown or indicated in the context where the block reference is referred.

In other words, if the [[note_name^blockrefid]] points to a list item with sub-bullets, it points to the list item including all its sub-bullet items. And![[note_name^blockrefid]] shows the list item and all its sub-bullet items.

And a maximum depth of the sub-bullet that is shown can be provided in the configuration, for the reason of simplicity.

Current workaround (optional)

A potential solution is provided in

by @argentum as:

However, I don’t think @argentum 's solution is a good one, as the solution actually breaks and damages the structure of the original list and original note which are referred.

Related feature requests (optional)

A more ambitious feature request about taking not only the sub-bullets but also the sibling bullets of the parent list item into account is posted here:

Davenukem · January 11, 2022, 8:12pm

Going to chime in here and strongly support the addition of this feature.

The current result is a little nonsensical - referring to the top level item of a list just shows that item which is of little value. Was actually surprised it worked as it did!

roberthaisfield · January 12, 2022, 6:22pm

Hey, chiming in here, it is very frustrating that I can’t refer to a specific bullet point in a vault by block ID, but can only refer to specific list items and it’s not even clear to me which ones I’m able to refer to such that Obsidian recognizes it. Of course, I can still search for the block ID and find it, even if Obsidian says “unable to find section in Page.” Issues with block-referencing nested lists - #7 by WhiteNoise

My nasty workaround looks like this:

line:(5w9511 OR 1apagf) -file:"title of page I'm on"

WhiteNoise · February 18, 2022, 6:59pm

Starting from 0.13.25, embedding list items will now show any sub list items when rendering.

malecjan · February 21, 2022, 1:59am

@WhiteNoise From your previous posts I assume that end-line block-IDs are preferred . (Except if list contains complex blocks like tables which need empty line before block-id according to help.)
Is that correct? I want to put correct update info into first post.

IMHO, this solves the most important need of this request. Thank you.

If I understand correctly, for now it will not be possible to embed only the block without sublist, neither sublist without main block. These cases can be solved some day after many requests of higher priority.

Some options:

by support of <span id="id1"> embedding block identified by html id attribute </span>. ![[#id1]]
by Support for Linking To/Embedding Ranges
Consistent syntax:
- ![[#^id1]] → only main block/item identified by block-id ^id1
- ![[#^id1..]] → main block with it’s corresponding sub-content/sub-list
- ![[#^-id1..]] → only sub-list without the main block
- ![[#-my-chapter..]]→ content of chapter (without it’s title): Or simply ![[#-my-chapter]] if ![[#my-chapter]] without .. transcludes whole chapter.

WhiteNoise · March 7, 2022, 3:24pm

I am going to close this FR as it’s going public soon. For any modification or additions open a new FR.