A general format for specifying links to a part of note (multiple paragraphs, ranges) / Embedding Multiple Consecutive Headings Or Blocks

Feature requests
61

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.

7 Likes
62

I’d love this feature! It’s literally the last missing piece for my bible studies in Obsidian!!!

5 Likes
63

Related syntax suggestion:
Add support for relative offsets from header/block anchors.

[[filename#header{0}]]
  • refers to the header block only, no following content
[[filename#header{2}]]
  • second block after header
[[filename#^block{-3}]]
  • also works with block ids
  • also supports negative offsets
[[filename#^block{-3;7}]]
  • two values separated with semicolon denote inclusive interval relative to one anchor
  • negative and positive offsets allow to capture context around the linked block
[[filename#header:#header2]]
[[filename#header..#header2]]
[[filename#header~#header2]]
  • two anchors separated by the separator symbol denote interval between different anchors
  • colon or two dots or tilda or whatever - I’ll take any option
  • second header anchor default offset behavior is up for debate
[[filename#header{1}..#header2{-1}]]
  • combine two anchors and relative offsets
  • semicolon in curly braces is disallowed here
  • this allows to capture content between anchors without the anchored lines
[[filename#header{1}~#$header]]
  • a symbol to refer to the last block of the header contents
  • dollar sign is my suggestion that reflects its common usage to denote the end of something
  • this should address the situation when the next header is unknown/inconsistent
  • (solves common request - how to embed section content without the heading)
[[filename#header{1}~#$header{-2}]]
  • also combinable with offsets
  • allows to skip templated content such as a separator line before next section
[[filename#header{1;$}]]
[[filename#header{1;$-2}]]
  • putting last block symbol into curly braces
[[filename#{0;$}]]
[[filename#{0}..#{$}]]
[[filename{0;$}]]
[[filename{$-10;$}]]
  • offsets computed from the beginning and the end of file when no anchors
  • I don’t know if # is mandatory - I’ll take any option
4 Likes
64

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:

![[target-file#[[this-file#header1]]..#[[this-file#header2]]]]
3 Likes
65

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: https://forum.obsidian.md/t/paragraph-list-block-range-transclusions/69841. It lists plugin Quoth that also supports transcluding ranges for OP.

2 Likes
66

This would be very helpful for me too

1 Like
67

I created a plugin to support linking ranges:

You can install in the obsidan community plugin search by searching “Link Range”

4 Likes
68

Use case or problem

A large portion of my obsidian usage is based on bible study, which splits things into obvious blocks (verses). I believe there’s likely others with a similar issues/use case however. My problem is how to handle transcluding a range of verses/blocks which is not necessarily the same each time (ie could be blocks 1-3 first transclusion, 2-6 next time, then 1-8).

For example, for a small snippet would be

1 Forasmuch ... among us, ^1

2 Even as ... ministers of the word; ^2

3 It seemed good to ... excellent Theophilus, ^3

4 That thou ... thou hast been instructed. ^4

Proposed solution

I think a simple way to do this would be to specific a “range” in the embed to combine transclusion of multiple blocks. Something along the lines of
![[my_note#^1-3]], ![[my_note#^1^3]], or ![[my_note#^1#^3]]
depending on what characters are currently allowed in block-ids.

Current workaround (optional)

Currently usage would look like this,

![[my_note#^1]]
![[my_note#^2]]
![[my_note#^3]]

which is clunky and results in a HUGE amount of space being taken up in preview mode before/after each transclusion (especially if I’m transcluding 10-15 blocks). Further, when navigating to the transclusion, only a single block is highlighted, and it would be great if they all were.

A plugin could also automatically split my proposed solution to this, but isn’t going to solve the clunkiness/space/highlighting issues.

Related feature requests (optional)

13 Likes
69

Use case or problem

I use Obsidian over outliner tools like LogSeq mainly because (in addition to other reasons like community plugins and vim) I find writing prose more natural over the endless bullet points of outliners. I also love Obsidian’s ability to link to a specific note’s heading (and heading content if embedded/transcluded), paragraph (‘block’), or list item / bullet point (and any sub-items if embedded/transcluded).

However, lists still have their place in prose. I frequently start a new paragraph as a sort of preamble to describe part of an upcoming list, then add a single newline and write the list itself. This is preferable to me because: ^qgjsz0

  • The preamble portion flows nicely with the rest of my prose and is easily copyable into emails/Github/Slack/etc.
  • Lists items are easier for me to read/process than prose when each item forms a cohesive and distinct thought in a similar category to other items
  • I can add sub-items to give extra details ^vx5xj4
    • As long as they are succinct

The paragraph/list above is an example of this, but I run into a problem when embedding links to blocks (![[note#^abcdef]]) this way. When only one newline separates a paragraph from a list, they are rendered close together in Live Preview (different than in this forum) and I consider them to be one collective idea (i.e., the paragraph preamble to the list is like the top-level ‘list’ item at 0 indent with all list items as subitems at 1 indent). But in the way Obsidian currently handles block link embeds, the paragraph and the list are always treated as separate blocks, so it is impossible to have a single link embed to the paragraph and render any following list items as well.

Proposed solution

I can embed the above bullet “I can add sub-items to give extra details” with ![[#^vx5xj4]], and in this case it correctly includes sub-item “As long as they are succinct”. I’d like to find a way to do this with the preamble paragraph text as well so that ![[#^qgjsz0]] displays the preamble and list. The only option I know of to do this is make the preamble an actual list item and indent the actual list to be under it, which is ugly, difficult to export, and doesn’t fit in with the remaining prose as it is essentially outlining. I could also just not have preambles for lists, but would prefer them for reasons listed above.

I’m curious if there’s a way around this / alternative solution, if others share the same interest for it to be an FR, and what problems I might be missing. For example, I prefer double-newlines between my paragraphs for readability, but maybe others don’t.

A workaround is plugin Quoth but as cool as it is, it might be too fragile for my needs. However, talking with the developer there gave me the idea of this transclusion syntax, which might solve not only this problem but allow arbitrary ranges of transclusion:

![[note#^beginning_^end]].

Any ‘blocks’ between ^beginning and ^end could be transcluded, or highlighted when clicking a regular link. I use _ because Block identifiers can only consist of letters, numbers, and dashes so there would not be conflicts.

4 Likes
70

Here’s another similar request: https://forum.obsidian.md/t/transclude-range-of-blocks/15551?u=i-d-as.

Perhaps another workaround would be to use a heading to contain the preamble and list so that they can be embedded elsewhere. Of course this requires there be another heading immediately after the list. Here’s a related request: https://forum.obsidian.md/t/header-level-support-for-linking-to-embedding-ranges/12347?u=i-d-as.

2 Likes
71

Good news, we can finally implement real multi-line blocks in obsidian;

Referring to the implementation of editable blocks in Obsidian-Basics, block link plus completes multi-line block references in the following way:

  • link: [[file#^xyz-xyz]]
  • ^xyz and ^xyz-xyz are arbitrary contents
abcde ^xyz

fghj

hmkl
^xyz-xyz
72

Hi. The link doesn’t work.

Here is alternative link https://github.com/Jasper-1024/block-link-plus

Can you provide more details how the new ^abc123-abc123 format works?

73

Just tested the link is valid, not sure if it is a DNS resolution problem;

The idea comes from Obsidian-Basics. When studying its inline edit block, I found that the final parameter it needs is file setartline endline.

So ^abc123 is the start line and ^abc123-abc123 is the end line; it works;

Of course, this involves a lot of style adjustments and live mode read mode adaptation issues, but the principle is like this.