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.
Proposed solution
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 workaround (optional)
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.
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.
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.
Ranges would be specified by embedded ‘begin block id’ and ‘end block id’ pairs. These would be similar to the current block id implementation only with a suffix added; ‘_b’ for ‘begin block id’ and ‘_e’ for ‘end block id’.
e.g. current block id: ‘^dcf64c’,
new range block ids: begin: ‘^dcf64c_b’ end: ‘^dcf64c_e’
The benefits of this enhancement would be:
Range linking would be backward compatible with the existing link structure; therefore existing files would not need to be changed and could incorporate both methods.
Block range links could be embedded anywhere within the content and would not require a prior blank line to signify start of block.
Ranges could overlap or be embedded in other ranges.
Final note:
In the example syntax I gave above, I used commas to signify range begin & end parameters. That’s because I’m partial to commas, but it doesn’t have to be that, there were some other great suggestions in this thread.
Another related feature I’m missing: being able to reference a block where certain link is present.
More specifically, for page backlinks I’d like to be able to construct links that would lead to the first place in that file where the current file is linked (I hope it’s not too confusing).
This would behave as an alternative to header/block reference and would require another special characters sequence, perhaps.
The challenge is that file names can contain almost any characters, and so any syntax would have to consist of #s, ^s and []s.
Most obvious suggestion, albeit might reveal some parsing challenges:
[[target-file#[[this-file]]]]
Minimal implementation should probably find first backlink of any pointing into this-file.
Behavior around embed links ( ![[]] ) is up for debate - it might make it even easier than now to create recursive embeds.
Combining with my previous suggestion, embedding first backlink context:
![[target-file#[[this-file]]{-2;2}]]
If more specific references are allowed, it would try to find most specific matching link…
(If full syntax is supported - this leads to recursive syntax, sounds fun, yay…)
Embedding a range between blocks referencing sections of current document, because why not:
I created a related FR today and later realized that something simliar to this FR (instead, block-level ranges in links/embeds) would solve that, and wrote about it a bit there: Paragraph+List Block Range Transclusions. It lists plugin Quoth that also supports transcluding ranges for OP.
