#1

EDIT: See my latest post for an iteration on this initial idea.

Got the idea from @macedotavares - a syntax for block referencing like ((12345|this is the block content)). Only the block content would get displayed. You could then embed the block via !((12345)).

What I like about this is how similar it is to Obsidian’s current [[link|display]] style, so it feels pretty natural.

Initial ideas:

  • Block IDs could be auto-generated via a timestamp - simply type (( to start a new block, which creates a (({timestamp}|)) structure, with your cursor placed just after the |.
  • Since it’s so similar to Obsidian’s style, you can convert a block to a file simply by changing ((block id|block content)) to [[block id|block content]]. Makes it portable.
  • Could support multi-line blocks, but would be a bit more challenging to make into a file as easily as an inline block. An idea to resolve this:
    • ((12345|
      This is the title
      Lines
      of
      content
      ))
  • Could get converted into a file called “12345.md” or “This is the title.md”, with the lines of content being the file contents. The converted link would either look like [[12345|This is the title]] or just [[This is the title]]. Might also want to strip any preceding # from the title, in case it’s a header
  • This could potentially support nested blocks, though I’m not sure how useful they’d actually be, since blocks are meant to be even more atomic pieces of information. Nested blocks would likely have to be under a multiline block to allow proper link conversion, since you can’t have a nested link! For block embeds, it’d likely need the same ‘5 levels deep’ restriction that Obsidian has for regular file embeds.
  • Could have a similar linking syntax for files - ((12345)) creates a link that takes you to the block.
10 Likes
Allow internal links to any element via anchor
#2

Thanks for expanding and improving upon my thoughts. I can see this working, yes!

The double parenthesis were already present in @ryanjamurphy’s previous post (to which I was replying). Anyway, this discussion is months old now (it began on Discord), and attribution becomes a tricky affair. I think it doesn’t matter at all, since it’s community work — but still.

Cheers!

1 Like
#3

Oh right! Makes sense this is part of a longer thread.

What’s attribution?

Oh wait, I assume attributing the original idea! I thought it was describing attributes of blocks or something lol.

2 Likes
#4

Yep :+1:

Now we only need to find prospects for plugin development and do the forum equivalent of an elevator pitch. :joy:

2 Likes
#5

By the time the plugin API beta comes out, I’ll be too busy with uni work to think about this too much. Although I have a bit of programming experience, it’s only in Python, so I’d also have to learn JavaScript.

Still, it’d be very cool to be a developer for an Obsidian block referencing plugin!

1 Like
#6

Hmm, was doing some initial testing with internal links (just HTML in Obsidian), and it seems like you can only link to either pages or headers, rather than any div with an id (which makes sense I suppose). So at the moment you can’t link to a block-like structure directly, only its parent file.

#7

I am personally such a big fan of declaring blocks. I think linking to a statement within a line or, as the OP indicated, over multiple lines, is a much more powerful and flexible framework than per-line blocks. It leads to a few possibilities, such as being able to use blocks inside tables (!) or having metadata-like phrases that can change across a set of files (e.g., If you have a bunch of files representing deliverables associated with a team project, you can put a block in each file like Person responsible: ((Kelsey)), then change that to Person responsible: ((Ahmed)), and have the change propagate throughout the project files. (Damned Kelsey, always a flake.)

Thanks for expanding on these ideas here!

3 Likes
#8

One thing we might need to consider is differentiating between a block creation and a block link/embed. With files there’s a clear natural difference (one’s a file, the other is just text), but with blocks it might be problematic to use the same syntax for creating a block and linking to a block.

For example, with this syntax, ((12345)) refers to a link to the block ‘12345’, whereas ((12345|This is a block.)) is an actual block, with id 12345 and content ‘This is a block.’ Might be confusing if we’re using the analogy of internal links, where both [[12345]] and [[12345|This is a link]] are links to 12345.md

1 Like
#9

Initial ideas for a proposed solution:

  • Creation of blocks is done by {{curly braces}}. When you create a block, you don’t need to make a title/id, though you can by doing {{id|curly braces}}.
  • Linking/embedding blocks is done using ((parentheses)). If you attempt to link to a block without an id, it auto-generates an ID (modifying both your link and the block in the file).

We also ideally want to make it easy to turn a block into a file. Perhaps we can use Obsidian’s inbuilt “what should the next new file be called” for the block id - so e.g. {{Untitled 1|block content}} when autogenerated. Or, if the user has the zettelkasten note prefixer on, it’ll have the timestamp.

In that case, we might be able to get away with the standard [[link|display]] syntax - the link would be the block id. It would be easier to only introduce one new kind of syntax, rather than two!

So, as a summary of an iterated idea for this:

  • Blocks are made by surrounding text in ((parentheses)), and optionally prepending a title via ((title|content)).
  • The title would either be auto-generated when linking to a block for the first time, or auto-generated when creating a block.
  • We might be able to have it so that blocks without a pipe have the content as the title by default. This is a little harder, since then block changes have to be reflected everywhere the block exists, in the actual link.
  • Blocks can be referenced like any other content via [[link|display]] syntax. This will show a clickable link with the text “display”, that links to the block.
  • Blocks can be embedded via ![[link]].
  • When viewed in preview mode on their original file, only the content of the block displays, not the title - similar idea to the ‘piped’ part of the link showing in regular internal links.
  • We might re-use the syntax for headers to extend to arbitrary blocks, so [[file#blocktitle|display]].
  • Since we’re using the above syntax, blocks could be simply numbered sequentially on a page (when initially generating the title), so Block 1, Block 2 etc
  • Searching for a block would have to be by title with how current search works, unless Obsidian implements searching via content (in which case we might be able to have blocks without a title work).
  • You can turn a block into a header and preserve links. Turning a block into a file would follow the same process as turning a header into a file would - this might become a part of core Obsidian functionality rather than something handled by a block referencing plugin.
  • Blocks can be nested in a similar way to how headers can be nested.
4 Likes
#10

This is a great idea!

1 Like
#11

+1. Windows.

#12

Is this still relevant after introduction of block references in v0.9.5 ? (Syntax is different but functionally almost the same.)

#13

@malecjan: seems to me too this issue can be closed.

#14

archived