Embed Specific Parts of a Block

Feature requests
1

Use case or problem

There are many times when I want to embed just a part of a block, not the entire thing. Currently, the workaround is to manually copy, paste, and add a footnote or some other reference back to the original. This approach isn’t ideal because:

  1. If the original content changes, these changes aren’t reflected in the copied excerpt.
  2. This manual process is time-consuming and adds too much friction, especially when dealing with many excerpts.

Proposed solution

Add an option to “Copy link to excerpt” or “Copy excerpt embed” (two separate options) when right-clicking on selected text within a block. This way, only the selected part can be referenced or embedded, while excluding the rest, and ensuring that any updates to the original content are synced by using the block ID as the link back.

Current workaround (optional)

  1. Carry-Forward allows to copy and paste with a link to the source block(s) appended to the clipboard.
  2. Copy Block Link, Block Link Plus and Text Transporter allow to quickly copy link to block(s) or block embeds.
  3. I also use a Templater script to copy link to block as footnote that I cobbled together. Although the script is somewhat redundant–this can be achieved with Carry-Forward.

All this is functional but not quite seamless. And none of these solutions address the main problem–they either facilitate creating:

  • Full block links/embeds, or
  • Copied excerpts with appended link(s) to source

Related feature requests (optional)

3 Likes
2

I just realized I used the word “portion” while you used “part”. Sorry.

Issue 1: Markdown

I’m fairly certain the “block” distinction is defined by markdown. Splitting those up into portions and rendering a portion in a new file’s embedding might not be simple.

Issue 2: Stricter boundaries would be needed to properly reflect changes in source

If the last half of a source text’s portion were deleted and then replaced with a different length of text, how much would still be included inside the embedded portion? If a source portion were entirely deleted and pasted elsewhere in its block, would the embedding’s snippet move with it, stay where it was as empty text, or absorb surrounding text? How could Obsidian tell?

You’d either need:

  1. The embedding to specify a length of characters, words, or sentences (like how embedding pdfs does with pages), which would do an extremely poor job of enduring changes to the source
  2. A clearly defined boundary between block portions, which would need to exist within the source file. Future changes in source content would be made with their location in mind. They might need labels so you can remember what they signify and so the embedding can refer back to it.

Given this restriction, block portions would be similar to existing Obsidian features

What I described in (2.2) is basically how block references (Internal links - Obsidian Help) and headers work. The only change-adapting way to link to source content is to have a solidly defined division of text, and Obsidian already provides 7, with blocks being designed to be the smallest.

If you need a portion of a block, you could just split it into shorter blocks. If you need to also embed a larger group of blocks, you could just use the 6 header types.

Issue 3: These boundaries would need to be more visually appealing than existing features

Whatever is used to split up your source text will likely end up thrown in the middle of paragraphs, and would need to be visually non-obtrusive. Headers take up a full line. It seems like block reference ids have to be followed by a couple of new lines (in making them separate paragraphs). Neither are ideal for this.

Issue 4: These boundaries would need to be more dynamic than existing features

Let’s say your theoretical button/keybind places block IDs (or headers) before and after the selected text, and also copies the final reference for you to then paste for your embedding.

If you embed portions of the same text multiple times in a hierarchical way (an embedding for a phrase, another for the full sentence, another for the paragraph), then your program would need to be capable of dynamically redefining what level of header or block to use for each. If there’s overlap (if text is “ABC”, embedding 1 contains “AB” and embedding 2 contains “BC”), then this keybind would insert boundaries in the middle of another embedding’s section, unintentionally altering it.

The core issue is that Obsidian’s headers and block references define one boundary, and rely on other references/headers to determine where the other boundary lies. For this system to work reliably, your keybind would likely need to insert a custom “start” and “end” for each embedding, each containing the same unique identifier. This would look messier and require a more complicated implementation than just using block references and headers, but better represents the block splitting you’re asking for, as well as block combining.

Issue #5: These boundaries might require some maintenance

  • If you get rid of an embedding, you might need to return to the source text to clean up.
  • If you remove a boundary in the source, the embedding would break
  • To keep track of what the boundaries are for, you would likely need to come up with your own label to use as the ID
  • Changing or restructuring the source text while trying to keep everything in the right places for these embeddings could end up being a hassle.

Conclusion

Overall, I feel like this is possible, but wouldn’t end up quite as intuitive as you’re imagining. It would have to work its way around multiple of Obsidian’s systems, so I’m not sure they’d implement this.

Simply breaking your text up into smaller blocks would essentially accomplish this.