@Silver
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.
3 Likes
Already sought out.
Works with every header.
Only remark:
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 [[ link?
@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
[[filename#headername]].
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]].
2 Likes
Here’s a video from the Foam developer with some interesting ideas about block referencing in markdown
5 Likes
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.
2 Likes
That would be perfectly fine and welcome!
1 Like
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.
1 Like
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!
11 Likes
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)
3 Likes
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?
2 Likes
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 ((double parens)).
Personally I think we’ll see many solutions to blocks when plugins are possible, and this’ll be one of ‘em
3 Likes
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.
Wouldn’t it be easiest to have it function like this: User can highlight whatever and press a button which designate that as a block – that block gets stored as a dictionary<string, int[2]> where the string is the file name, and the two ints are the start and end point within the file.
Then the program just needs to have a list of such dictionaries to comb through?
Yeah, another markdown deficiency. Paragraph markers used to be normal, and exist still in word processors.
One easy syntax for a block ID which is consistent with markdown is to use ####### (h7). Markdown doesn’t process it as a heading. Some parsers do change the appearance (making size the same as h6), but it’s generally ignored, so wouldn’t interfere with functionality in other markdown programs. And easy to interpret because it follows a normal markdown syntax in a very similar role.
You’d have to do something to save having to count #s , but you have to do that anyway. I use a text expander.
I think its a bit more elegant than subverting h6, as has been suggested, as it doesn’t interfere with other programs, and documents prepared in other programs would still function as designed.
3 Likes
As with other headings, you’d either write a title or you’d make the whole block the ‘heading’.
1 Like
@Dor: then what’s the difference with a regular heading?
The issue was to be able to link to smaller units rather than to paragraphs currently headed with a header, without having to put headers above single sentences.