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?
This must be how they do it in Roam. Funny as hell, though.
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
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.
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!)
From the Insider channel on Discord:
The main rationales for the change from
- 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.
# at all?
#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
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 $$ :::
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!
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!
2 posts were split to a new topic: CSS snippet to render embedded block references inline?