#180

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

@Wet: excellent points.

#182

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

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

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!

#185

Annuntio vobis gaudium magnum.
Habemus versus nexum.

13 Likes
#186

@WhiteNoise: Wonderful news - thanks for this!

#187

This is in insider build now.

11 Likes
#188

Could someone show me an example of this being used?

1 Like
#189

Here’s a super simple one.

Edit:

Screen Shot 2020-10-19 at 4.51.03 PM
Screen Shot 2020-10-19 at 4.51.03 PM764×599 53.3 KB

Preview:

Screen Shot 2020-10-19 at 4.51.00 PM
Screen Shot 2020-10-19 at 4.51.00 PM764×599 54.2 KB

Using the Minimal theme (Minimal Theme)

2 Likes
#190

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

#191

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

#192

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

#193

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

7 Likes
#194

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

1 Like
#195

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.

#196

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

#197

You just remind me about a bug that I has reported. Since the block reference is a link to a line in the other note, maybe the insiders can do me a favor to see if the bug is also valid for block reference.

  1. create a note-a
  2. In the note-a, create a block reference link to an item in a list within note-b.
  3. change note-a to preview mode, and click the block reference link.
  4. in the new windows(also in preview mode), I want to know is it the item being highlighted or the entire list is highlighted?
#198

Oh, I understand.

As one can always give a name to a link by [name](link), the text of the link is not have to be readable.

It seems that I confused [[]] with []().

#199

In the example I posted, the todo’s block ID was randomly generated. You can also append your own to the end of a line. ^likethis

I could then write ![[this note#^likethis]]* to get at it, and you can use custom IDs to infer what the item contains while in edit mode.

(*incoming syntax change for block as we experiment in Insider: the links will soon require #^ instead of just # so that they’re more apparent and block IDs are more easily searched, among a few other benefits; thanks to Insiders for the feedback!)

2 Likes