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

@Licat

Why
[[Filename#^blockid]]
And not
[[Filename@blockid]]

Sorry to revive a closed topic

#202

From the Insider channel on Discord:

The main rationales for the change from [[Filename#blockid]] to [[Filename#^blockid]] are:

  • Makes it easier to search, potentially outside of Obsidian.
  • Makes it more obvious and distinguished that it’s a block reference, helps scripting/batch processing.
  • If you end up going back to change the block id, you won’t get auto-complete for headings.

Why # at all?

Because # is the character we use across the app to split a URL into the “path” and the “subpath”
It’s also the character URLs uses to signify anchors

1 Like
#203

thanks

1 Like
#205

How about to use ::: to specify a complex block content(simlar to pandoc)? like this:

::: ^a_block_id
 we have a paragraph.

and a table:
| a | b | 
|:-:|:-:| 
| c | d |

and a formula:

$$
E = mc^2
$$
:::
2 Likes
#206

OK, I’m excited about the new capability, but dismayed that yet another new syntax for block-level references is being invented. There’s a real risk of fragmentation and loss of standardization here:

  • Obsidian: [[noteTitle#^blockid]]
  • Roam: ((blockid))
  • Extended Markdown: Descripive text

Portability to Roam isn’t important, but portability to other Markdown apps that may want to implement block (or header-level) linking should be compliant.

OK, I’m conflating header and block-level linking. In which case then, it would be great if Obsidian could also support header-level linking (then, the original syntax chosen for block references, [[noteTitle#Header]], with auto-complete, would make TOTAL sense!

1 Like
#207

Obsidian already supports heading-level linking.

https://publish.obsidian.md/help/How+to/Internal+link

#208

This thread is archived. If you have further proposal or refinement about block reference, open a new and specific feature request and follow the new template.

#209

As a counterpoint, the current syntax is not too far from what Bear supports right now, which is arguable simpler (the / gives a feeling of “namespacing within a note”).

But having this at all is great, kudos to the team!

#210

2 posts were split to a new topic: CSS snippet to render embedded block references inline?

#211