Please speak English on the forum. If you want, you can add a Chinese translation at the bottom of your posts.
I created a feature request that might be relevant for people who want/need block-level references. It’s not necessarily a replacement for blocks, but it might cover some use cases. It would be useful to be able to create links without having to remember which file or section has the content being referenced. If the links suggested at the moment of typing would include content, after selecting a suggestion, a link with the right location in the right file would be inserted, e.g.
In case you think that might be useful to you, please give it some love: Suggesting links based on content
This is a very good “discussion” going on…
I’d like to make some other suggestions reading all this:
- The idea of the atomic note is for me (personally) a building stone of a good PKM-system.
The remarks of @juvoni about Block Referencing and Block Transclusion (which are two very different things) were very insightful and got me thinking…
- I tested some things and saw that when you drag a note from another vault into your current vault it creates a copy and references is with
![Block Description](Block Reference)in the current vault. I understand that this is linked to the “New link format” which is set to “Shortest path when possible” (correct me if I am wrong).
- I also would like to add that I really like the idea of adhering to the MarkDown standards and the basic Obsidian Manifesto which is explained on the website.
I do understand people who want to have Roam-like features. My honest meaning (which I also read in some remarks) is that the makers of Obsidian should stick to their basic ideas and not give in to make a Roam “clone”, which I don’t believe is going to happen seen what great suggestions come from the community.
That being all said (sorry for the long intro):
- Would it be and idea to explore the idea of storing metadata in an Atomic Note (Zettle) and do Transclusion of the metadata Zettle into the Zettle/Note you want?
I need to do some testing here as I still don’t have a solution for Relative Path referencing which would keep your Vault easily transferable as we would adhere to the MarkDown standards. Again I don’t believe building proprietary stuff or Add-ons to achieve this will help the ecosystem in the long term. Obsidian is really great (and I mean that) but there is no one who can tell if some other even better system will emerge in the future (I doubt it but OK ). I also understand that some people “mix” different softwares to maintain their Second Brain. Not adhering to the MarkDown standard would be nefast for those people.
- Another thing which I really like about Obsidian is the fact that you can freely edit your Zetlles in every outside system. I use this method a lot to add new block references when I am creating new research. This is something which Joplin does not allow at all so keep this great feature please!
Let’s try and find a good solutions which adheres to the MarkDown standard and keeps the Obsidian Manifesto alive. In my honest opinion the makers should try and keep that also in mind when opening the Obsidian platform for third-party add-ons. Not saying you should build an Apple ecosystem with very strict rules and kick out everybody and everything you don’t like. I would nevertheless not allow add-ons which violate the standards and start creating MarkDown files that are not usable in other environments without first having to convert them to ‘normal’ again.
Looking forward to see a good solution emerging for this issue!
From what the devs have said I understand they won’t go for block references. They have implemented links to headers (I personally use that a lot in combination with transclusions) and that’s it.
I am quite happy with their decision now that I have more experience with header links and transclusions.
Thanks for mentioning this. I wasn’t aware of the new ‘developments’.
Would you comment mean you are ‘forced’ with the H6-approach you also mentioned in the discussion or can you link whatever header you want?
From DIscord →
Licat: “Officially the core app will stay at heading level references. Once plugins opens up it’ll be up to a plugin maker to implement block reference however they want with respect to syntax.”
How block reference is done in an app called liandi:
“Basically the way block references are done is that Markdown is parsed into a tree of blocks, and the app assigns an ID to each block, which is saved in the JSON. The original markdown file is then discarded and the JSON is the new source of truth.”
Silver: “I have heard potential plugin authors come up with solutions that do not require converting Markdown to JSON but instead add IDs inline, which may still play well with the other apps that understand markdown.”
Good remark on the “other Apps that understand MarkDown”. Goes with my latter remarks on keeping the ecosystem of add-ons clear.
Letting add-ons transform MarkDown in a way that other MarkDown systems wouldn’t be able to ‘understand’ the files anymore is in my opinion the creation of proprietary format.
My opinion (personal meaning) is that such add-ons should not be ‘promoted’ in the Obsidian ecosystem or at least with serious caution warnings regarding portability and usability when working with different softwares.
Already sought out.
Works with every header.
You would need to know the name of the header ( ).
Can’t we just display the available headers in the notes when
#is typed in the
@RikD: yes. So, you start with
[[, get presented with a list of note titles,
- move your cursor to the one you want, but do NOT click on it,
- instead, type
#, which will result in a list of all the headers in that note,
- when you have found your header, click on it.
Bonus: when you have followed these steps, you get an ugly looking ling like so
What you can do is after step 3 you can type
| (= pipe character), then type a name for your link and it look like
[[your chosen name]].
20 posts were split to a new topic: Link suggestion is not triggered when
# is typed
Here’s a video from the Foam developer with some interesting ideas about block referencing in markdown
This looks very promising, hope Obsidian is considering how they might do this in the future too.
Effectively adding a UID isn’t it? Licat has said he’s not keen on that as a solution.
I think he anticipates someone addressing the issue when the API is out, possibly with a little database. As a plugin, users can choose to use it or not but the md remains intact. If someone produces a UID alternative, then they could choose that instead.
I think the option will come via a plugin.
That would be perfectly fine and welcome!
I have seen Licat and/or Silver state explicitly that they will not implement block references, links to headers is as far as they’ll go.
With the important caveat that it’s likely we’ll see multiple plugin options for block reference to suit everyone’s tastes!
Chant with me, everyone: API! API!
I have no idea if someone already proposed this since there are so many replies that is actually quite hard to follow.
I’ve seen many people obsessed over how Roam has an id for each block and then they use that id to be able to reference to a given block on a given note.
One way to work around that is to don’t use ids at all and hash the contents of the block instead. This is akin to how git or merkle trees store and addresses all pieces of content. If one changes the contents of a given block, then Obsidian can search and replace the references to the old hash with the new one.
Example: Let’s say you want to reference a block on the note "Block Reference.md with the content of “Obsidian does not need ids”. Imagine that the first characters of hashing that piece of content are “n01ds” (you don’t need the whole hash, the likelihood of collisions on a given note is very low). Then one could reference that block with something like this ((Block Reference#q2pm)). If I changed the content to “Obsidian is awesome” and that content produces the hash “4ws0m”, then Obsidian could replace the old reference to become ((Block Reference#4ws0m)).
Regarding how to produce those hashes in the UI it should be fairly easy: Exactly like it does with headers, but instead of inserting the contents of the block it would insert the n first characters of the hash.
Solved! (or not, I’m just theory-crafting here)
I’ve been thinking about this on and off for years, more for the challenges it presents (when dealing with plain text files) than an actual need of the functionality. I always enjoy reading about different approaches.
How would you define the beginning and end of the block?
Hashing the contents of a block are what I’ve been advocating for, too, although I haven’t posted about it in this thread.
@macedotavares New lines? Or, my favourite option: require that users declare potential blocks as statements anywhere in a text, e.g., with
Personally I think we’ll see many solutions to blocks when plugins are possible, and this’ll be one of ‘em
I’ve always wondered why text paragraphs don’t have this kind of ID as a system-level option or default. It would be so useful in many contexts and apps. The overhead would be worth it IMO.