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.
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 
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.
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.
- create a note-a
- In the note-a, create a block reference link to an item in a list within note-b.
- change note-a to preview mode, and click the block reference link.
- in the new windows(also in preview mode), I want to know is it the item being highlighted or the entire list is highlighted?
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 []().
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
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
thanks
1 Like
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
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
Obsidian already supports heading-level linking.
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.
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!