Block reference

@Dor: thanks for that explanation. To a non-geek Obs user that makes sense. Hopefully they’ll implement it, with or without a combination of some of the other solutions proposed here.

Thanks.
My own preference would be no title, and analysing sufficient characters in a block to achieve uniqueness. (Start with x and add 5 to that number when a clash was encountered.)

The big advantage of this approach is that it looks like markdown and doesn’t need a database. And hopefully that would be enough for Licat to be happy to incorporate it in the main program.

The disadvantage is that the extra processing would bring forward the point where the program slows.

1 Like

I try to picture a solution that could be implemented manually. I like Christian Tietze’s way of thinking regarding automatic link suggestions in The Archive — something that we in Obsidianland take for granted.

More specifically, I try to adopt the Wizard of Oz experimental paradigm he mentions in the article: trying to break down the desired feature into steps that you could reproduce manually; doing it in a software agnostic way.

From this perspective, I think line numbers are too fragile: if you just count the lines until you find the referenced block and include that number in the referring text, you could end up with something like ((other file.md|42)) and that would work. But if you edit other file.md above the referenced block, line 42 wouldn’t be the right one anymore. Furthermore, lines wouldn’t allow you to reference sentences in the middle of a paragraph, for example.

I believe there should be some kind of identifier (be it a timestamp, a hash, a UUID or something shorter, etc.) and a syntax that defines the boundaries of the referenced block. And that reference should only be created on a per-need basis. So, in other file.md I’d have “Lorem ipsum ((wH473V3r|this right here is important)) dolor sit amet.” and reference it with ((wH473V3r)) anywhere I need to.

This would give obsidian all the info it needed to do its magic, like hiding IDs, replacing them with referenced text and synchronising changes. But, more importantly, it would allow anyone in the future to do it manually.

I think you’re right. There will be a lot of plugins to choose from and, as much as I’d like to believe I’d be able to code one of them, the truth is I’ll probably just benefit from someone else’s work. This is the limit of my contribution. I hope it helps, even if it’s only by fuelling the discussion.

3 Likes

That’s on point.

I am totally fine with block reference on the level of headings, and I’m looking forward to the mentioned improvements.

I actually find the approach to use files as blocks and to keep them short and snappy practicably superior to full block referencing since it somewhat forces one to put some thought into the note creation.
I think this is especially true in consideration of the awesome popover preview functionality and an extensive use of MOC’s.
With the additional flexibility of (fully functional) block reference at the level of headings, I can’t see much value in implementing a Roam like block structure at all.
When trying and looking into Roam, I even found it too atomic and too easy to get messy with.

2 Likes

@Wet: excellent points.

This is a very important point IMO. Taking proper notes also means that I have to think more about what I want to state with this note. E.g., being forced to write a title for the note means that I have to come up with a short summary (or core statement) of what this note is about. IMO, performing this little extra step is truly helpful in the long-run, since it helps to increase the clarity of my notes, and sharpens my senses.

This is even more true for the act of “transcribing” the note’s thought with your own words in the comments of the note.

In addition, I think it’s important that I can reuse my notes in external applications. With block references, unless it‘s a software agnostic implementation, this may be tricky.

Also, what happens if you’d like to expand on a block, and convert it into a proper note? This likely would require the app to help you with converting all the links to the block into proper note links.

Block references are surely nice for quick reuse of little bits of text. But they should not replace the creation of proper atomic (& self-contained) notes. Long term, the latter will likely help you better to achieve structure & clarity in your notes archive.

3 Likes

@macedotavares This seems like a nice syntax! You might get it so that Obsidian auto-generates an ID in place if you don’t supply one, and this blends well with Obsidian’s existing piped link syntax - the part after the pipe is what you actually want to display. Might even allow nested blocks! Though I’ve no idea what use you’d have for that…

And as you say, it allows people in the future to do it manually too, even outside Obsidian - one could imagine writing a parser that generates a separate file for each block, with the title being the block name and the content being the block itself. So it’s portable too. It might even be as simple as just replacing ((block id|block content)) with [[block id|block content]] to generate a note.

1 Like

Yep, I need this block! The block can help us link everything, besides, if this block can be collapsed and expanded it can be better!

Annuntio vobis gaudium magnum.
Habemus versus nexum.

13 Likes

@WhiteNoise: Wonderful news - thanks for this!

1 Like

This is in insider build now.

https://forum.obsidian.md/t/obsidian-release-v0-9-5-insider-build/7260

13 Likes

Could someone show me an example of this being used?

1 Like

Here’s a super simple one.

Edit:

Preview:

Using the Minimal theme (Minimal Theme)

2 Likes

It looks that in the editing mode, the block reference will not be readable.

I assume that will improve once we have the WYSIWYG editor.

@GLight: that makes sense, a block reference is just a link, after all.

I didn’t see this one coming! So what else have the devs been silently working on? Cold fusion?

7 Likes

This must be how they do it in Roam. Funny as hell, though.

1 Like

if you use [[note_name#title]] rather than ![[note_name#title]], in both the editing mode and the preview mode, you get a readable content which is self-described. But with something like this, well, I guest the ![[]] or [[|some text]] are the only possible ways to use it :joy:

Perhaps, I’d like to excerpt the content from the other note directly or take the content as a footnote.

@GLight: I have not had any readable content with any form link in Edit mode. Unless, we’re not talking about the same thing. The only thing I get is the text of the link itself, and only in Preview is rendered, whether that be a link with or without a ! in front.