Newbie comment. Working myself away from Notion where you can define arbitrary sections of a note to embed elsewhere. Seems to me a “top fence” for a named block would make total sense as a manual override to the automatic logic. For example
^GroupBlockName
These are some
elements I want to embed elsewhere
regardless of formatting
^GroupBlockName
Change the delimiter on top fence however you like, but the functionality of a manual declaration is missing IMO.
Hi all!
I see the use of header-references, but I would also VERY much like to see custom block-references. Maybe, as @GregMon said, by using a top-bottom-fence syntax, or by being able to use the same block-reference name for multiple blocks, which then joins them upon referencing.
My specific use-case is as follows:
Could this feature be reconsidered?
In the meantime, do you have a solution to my 1st use-case?
Cheers
ABKane
I like to see a solution to this problem too, still using headings for referencing multiple lines and it is a very ugly and high friction workflow for me.
I would definitely use a functionality like @GregMon described. I have notes that are long texts separated into chapters and paragraphs, and I reference these notes in many other places. Most of the time, I don’t want to link the entire chapter OR a single paragraph, I want to link a 2-6 paragraph section of the chapter. Having to create hidden headings or separate notes to define the specific blocks I want is very time consuming and clunky.
Late to the conversation, but I just wanted to note that you can embed multiple blocks if they’re included in the same callout. I find this useful in a lot of cases, but it’s not going to work everywhere.
I’m trying to get block references working and stumbled upon this.
I suppose a bullet list counts as a separate paragraph/block element? So I would also be interested in a way (besides headings) to link to a block!
The reason I’d like to use it without a header is for embedding it as I’d like to include my own title in the outline of the file I’m embedding into
Hello, the needs of multi-block reference have always existed.
Before the official resolution, I wrote a header-based multi-block reference plug-in: block-link-plus .
The implementation of header-based is not perfect, so just for those who need it.
Using link to block functionality, I had to face the following limitations:
(this is probably not a complete list of the limitations of link to block functionality - I’ve only mentioned what I’ve encountered personally)
As a solution, I see adding functionality to create links to selected text, similar to the identical feature in PDF Reader.
Aliases for search: selection, reference, block, link, deep, linking, embed, embedded, embedding
Just to clarify your request, are you talking about embedded block links? You only mention linking in this post, but the issues sound particularly relevant to embedding.
So I guess I’m suggesting to add to your search aliases: embed, embedded, embedding
Possible implementation is to use span tags and id attributes:
text <span id="123">my text selection</span> text continues
The current block id notation assumes a block but this same notation could be extended with curly brackets to include inline stuff text {my text selection}^123 text continues. Curly brackets are not usually used in natural language although they are used with templates core plugin etc. Curly brackets wouldn’t make the source text in source mode too difficult to read compared to html tags.
If “embedded block links” is ![[note#^h57dbt]], then in my “Use case or problem” section I describe the limitations of the current implementation of Link to block functionality, and… the fundamental problem is not the act of “embedding” the link itself, the fundamental problem - as it appears to me, as an ordinary user who does not know the implementation of this feature from a technical point of view - is determining the part of the document to which the link should be created - regardless of whether the link to this text will later be embedded (![[note#^h57dbt]]), or not ([[note#^h57dbt]]).
So, paramount to this request is precisely the ability to more flexibly define what part of the document the user can create a link to. And the most flexible option that can solve all the problems that the current implementation of the “Link to block” feature does not solve (which I personally had to deal with) is to create a link based on the selected text - even if this selection affects several blocks, and even if this selection affects some blocks only partially (including “non-linear” text selection made with several cursors/carets created with the Alt key).
As for all the other functionality inherent in links, whether embedding them or whatever, I didn’t mention it, because I considered all that functionality to be… auxiliary? dependent? … and that when such links can be created, they themselves imply that they should have the same functionality as any other links.
This is also the reason why I didn’t mention that if this solution requires the creation of an individual syntax, as described in https://forum.obsidian.md/t/block-reference-for-multiple-paragraph/7674, then this syntax should be hidden in Live Preview, and not visible - just like the syntax of regular links.
But if it is worth mentioning separately, then… even if the functionality of embedding such links will not be implemented, it will not be critical for me, personally I can do with a regular, not embedded, link.
But if this functionality will be implemented, it will also be good, because I still from time to time insert links to blocks as embedded, and it will be more comfortable if when such functionality is needed, it will be available.
I hope I haven’t caused more confusion with this answer, although I have my doubts about that…
If I have, and the request remains unclear, let me know and I will try to explain it in more detail, accompanying the text with screenshots with examples of what I mean.
I also thought about implementing this function by enclosing the text to which you want to create a link in curly brackets.
This approach will even allow to create links to “non-linearly” selected text located in different blocks - just assign the same id to them.
But I decided not to mention this solution, because when I looked at the format of a link created to selected text in PDF ([[Charlotte Brontë - Jane Eyre.pdf#page=579&selection=33,9,38,34]]), I thought that there is another way to create links without clogging the text with their syntax, and the developers could probably come up with a better solution than the one I came up with.
But on the other hand, the text in PDF is static, and in notes it changes quite a lot, so if when creating a link to refer to, conditionally, the serial number of the symbol from which the link should begin, and to the serial number of the symbol on which the link should end, then when you change the body of the note, the whole link will simply “crawl”.
So, probably, the implementation identical to the implementation of the link to selection in PDF is not quite relevant in this case…
I agree but one could also auto convert notes to pdfs to get links to selections. Currently this can be done using Advanced URI with confirm parameter and Shell commands with file moved event. I haven’t tested this and obviously this is kind of advanced stuff.
I heavily use internal linking and embedding in my notes. However, not all of the things I’m linking to fit neatly into a hierarchy, where I can just embed/link a single block or heading. Thus, I find myself having to add links to multiple sequential headings or blocks in the same document. Instead of having to add this list of links, it would be nice to be able link to a range or headings or blocks in another document.
Sample Doc A:
filename: Genesis 001.md
---
# Genesis 1
## 1
In the beginning God created the heavens and the earth.
## 2
Now the earth was formless and desolate, and there was darkness upon the surface of the watery deep, and God’s active force was moving about over the surface of the waters.
## 3
And God said: “Let there be light.” Then there was light.
Sample Doc B:
Allow hash fragment to link to a range of headings (here using a hyphen as the range separator, but this could be something else):
See [[Genesis 001#1-3]]
Current work around: include multiple single-heading links:
See [[Genesis 001#1]], [[Genesis 001#2]], [[Genesis 001#3]]
I would really like this. I came searching this forum for exactly this and this represents my use-case pretty well.
I think the proposed syntax needs to be tweaked a bit. Perhaps:
[[Genesis 001#1-#3]]
I think that would make it more clear that the 3 is another block below the first block.
I’m not a programmer, but I do wonder what would happen if a block had a “-” in the name. That might be the thing that makes this the most difficult to implement. Maybe something like this could solve for that:
[[[Genesis 001#1]]-[[Genesis 001#3]]]
That doesn’t seem very elegant either.
Bottom line: This seems difficult, but I would love to see it.
+1 for this request! 
Also, dendron currently supports this syntax:
![[NAME.OF.NOTE#STARTING-HEADER:#ENDING-HEADER]]
Might be nice to be compatible.
Related feature requests:
I would love for heading embeds to simply respect the heading hierarchy. In other words, given this content:
## Test Heading
Content
Content
### Child heading
More content
## Next Sibling
This embed code: ![[link#Test Heading]] would display all of the above text until the “next sibling” heading. That is, embedding a second level heading would also automatically pull in third, fourth, etc level headings.
Yes! Please this! Working with policy would be much easier if hierarchies were respected
That’s a good idea, but it is really a separate feature request. The original post is about linking to or embedding ranges of blocks that are at the same heading level.
Hyphens are expected occur in heading ID as explained e.g. here.
So I proposed two dots (periods) “..” as a separator to denote ranges, with reasons explained in A general format for specifying links to a part of note (multiple paragraphs, ranges) / Embedding Multiple Consecutive Headings Or Blocks - #2 by malecjan