Header level support for Linking To/Embedding Ranges

Use case or problem

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.


+1 for this request! :+1:

Also, dendron currently supports this syntax:


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



### 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

1 Like

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.


2 posts were merged into an existing topic: A general format for specifying ranges in internal links

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 ranges in internal links - #2 by malecjan


I too could really use this functionality, here is what I propose:

in the ‘new improved linking’ there would be

  1. consecutive sections ranges: [[filename#begining section, ending section]]

  2. block ranges: [[filename#^beginning location, ending location]]

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:

  1. 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.

  2. Block range links could be embedded anywhere within the content and would not require a prior blank line to signify start of block.

  3. 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.