Thinking… , 
There are two problems with this approach. The first one is that it assumes a pure, 100%, contents-only atomic note. The second one is that it creates a couple of extra steps . Expanding on the two problems below.
Atomic notes are not atomic: As mentioned here. Take this very example. Let’s say I have an atomic note that says “Atomic notes are not really atomic, for they have some kind of meta data added to it in a Markdown-based systems like Obsidian”. I would like to add at least two elements to this note: where it came from and other related notes. If I add these bits of information, my so-called atomic note is no longer atomic. It bears not only the content itself, but other information. If I reference this note (by transclusion, for example), I’d also be including its meta data and the links to related notes, which I may not want to do if my interest is only on the core of the note itself.
Extra steps: We are interested in doing exactly the opposite of creating extra steps. Adding extra steps is taxing on ones cognitive system, which degrades understanding and learning. This seems a too expensive side effect. Taking the extra steps argument to the limit, Obsidian itself is not needed. For one can always implement atomic notes in an analog index card system and achieve great results. Luhmann’s intellectual production is a demonstration of that.
In summary, although it is possible to create (cognitive taxing) workarounds and in spite of the technical challenges of developing a block reference system on top of a plain Markdown file structure, it is possible and useful to develop some kind of block reference in Obsidian.
7 Likes
If you like the Roam approach so much, why not simply use Roam when it’s clearly not straightforward to add this feature to Obsidian.
I’d also disagree about the cognitive tax. It’s taxing if it requires a habit change because you are coming from another system, but otherwise it’s minor.
As a separate point there is a recurrent tension between users wanting a more reflective Luhmann type approach, and those pursuing a high number of outputs as in GTD etc. Your comments suggest that you’re more in the second camp?
1 Like
I don’t think it’s a Roam-specific feature, per se, although Roam popularizes it. Before Roam, I already was doing citations to specific paragraphs in my notes written in other note-taking tools. Particularly when I am writing a long train of thoughts that incorporate points made in paragraphs from other notes, the switching between notes exhausts me.
The reason I switched to Obsidian from Roam is because the cost of Roam doesn’t make sense for me. I like Obsidian the way it is, but I don’t think people advocating for block references are doing so due to their habits formed when using Roam, but rather from a position where they the benefits of such a feature.
If you would like to argue that, the habit change which is equivalent to forsaking the pursuit of block references, would actually benefit the users in the long-run, as opposed to increasing cognitive load as discussed above, I’d be interested in hearing that.
3 Likes
What would be wrong with a very simple system of markers to mark the block, that either include or exclude the ##header that identifies it? So you could have, for example:
{{ ### My awesome quote
My block text
}}
or
### My awesome quote {{
My block text
}}
In either case, you would include this elsewhere as
![[my_file#My awesome quote]]
Obsidian already supports this form of header-level referencing, I believe. The first form would include the header/block name in the transcluded text, and in the second case would skip it. I understand that the goal is to stay as close the standard markdown as much as possible, but [[ ]] is already non-standard. This seems to fit the philosophy of link as first class citizen even if it introduces a small deviation. And it looks not entirely unlike a bit of LaTeX or json code with the use of delimiters to mark out a region for special treatment, which is probably familiar to this community.
I’m not a fan of all the hidden line IDs or other mechanisms, which seem complicated. Better to mark and name the block, which will still work if you add, remove, or shuffle other things in the file, or change the contents of the block itself. Would also be obvious in non-Obsidian markdown editors that this block was marked and named for a reason, and wouldn’t be too visually offensive.
6 Likes
afaics Roam keeps all your notes as a single dataset. The block is a key concept in design and optimisation of its database. This makes it fast and flexible working with blocks.
Obsidian is a database working with notes held in separate document files. Links to Documents and Headings are straightforward because they are native features of those documents.
I don’t see how it can ever process blocks as effectively as Roam.
The downside for Roam is that it’s stuck with blocks, just as Obsidian is stuck with documents. There are many ways of thinking about working with sections of text. I think it would be most useful to consider the detail of various needs rather than talking about blocks.
For instance, doing textual analysis there may be a use for analysing portions of text, where the portions may overlap. Neither Roam nor Obsidian have an elegant solution to that right now- multiple links to the same word require a different solution to [[ in the original file. I think Ryan is right in his approach, though the program would need to heavily tweaked to make it fully effective. Micro plaintext files are managed very effectively in all OSs. A selection that created a new linked file could work with any and all portions of text - but there would need to be an effective way of displaying them in the original document.
2 Likes
@greasemonkey I try to not look at this as a difference in opinion because that can shut us off from finding something of value in what the other is saying - like 99% of internet talk I suppose 
This discussion allows some people to already find a partial solution that can work for them right now, which is great on its own.
Then others can share why exactly it won’t work for them and this is extremely valuable because let’s face it: there’s a lot of smart people here and those tend to have difficulties dumbing things down, as in their minds the problem is THAT obvious, it’s hard for them coming up with words to fully describe it.
There’s some great insights shared so far by both yourself and everyone else who posted.
For example based on your multiple uses of the words “friction” and “pulling” blocks, I now wonder how people would feel if the problem on how to STORE blocks got solved but we would then always need to type in order to RETRIEVE a block when including it in another page.
Would such a solution still carry the same amount of friction? In other words, when you refer to “pulling blocks”, is it the act of dragging and dropping blocks between documents which contributes to the feeling of efficiency?
Then back to the other side of the coin on how to actually store the blocks in the first place:
I’m sure eventually people will develop multiple flavors of plugin solutions as some want bullets, others want paragraphs, others just lines, etc… and those plugins will be a good fit covering those specific needs.
The risk is with other people not fully understanding some of the intricacies these plugins will bring along when they require storing foreign block indicators inside markdown files.
Everybody can of course accept that risk when using such plugins but nobody wants to see theirs or someone else’s life work get mangled due to the inner workings of a plugin conflicting with another app and/or human error update.
That’s why a fully portable and truly robust solution which can be safely distributed to a wider general audience will most likely need to stay closer to the Obsidian foundation using plain markdown documents.
I’m not a developer and don’t care much for markdown - so don’t know this suggestion is of any use at all, but maybe we need to look closer at using plain markdown without requiring extra foreign indicators in the file?
For instance by using a simple numbered list.
A plugin could validate numbered lists ensuring they are sequential and unique within the document(header). Then couldn’t that regular number be used as the block ID?
Something along those lines would feel more robust to me, easier to comprehend for the average user as well, be portable, and if something does get mangled wouldn’t require the SpaceX team to come in to fix your files.
4 Likes
To piggyback on @ja_rule’s suggestion, one way of referencing blocks that currently exists is to enclose text in an h6 (######) ‘block’:
###### If you dislike folding
If you dislike folding for whatever reason, it can be turned off in Settings.
######
###### A really great quote
> Obsidian rocks!
> \- Anonymous
######
The second ###### acts as a terminator to delineate the block.
Then use obsidian.css to hide h6 (whoever used an h6 with a straight face though, really?):
h6 {
display: none;
}
Using the first few words of the sentence/block in the h6 heading works nicely when autocomplete kicks in during link creation (as opposed to using something like an ID).
I’ve never had the need to ‘title’ a block reference, so it seems fine for my use that the h6 is used as a reference, but never rendered.
11 Likes
Hi all,
I’ve used Roam for almost half a year now and I used block references very heavily. However, I played around with Obsidian a tiny bit and I liked how polished it is. I think that except for the lack of block references and a scratchpad, it fulfills almost all of my needs. Block references are really important to me, because people were quickly overlooking the power of block references, I made a quick video to showcase how I use them.
Here’s a review of Obsidian that I shared with my peers at Roam’s Slack
So I hope you can believe me when I say I’d really like to see a block references solution in Obsidian. I can leave the scratchpad feature aside.
While browsing this thread, I saw some clever solutions.
If I want to reference to a passage of text, I could just create a third page where the “block” lived and then reference it in both pages (the original one and the referer). Automating this via highlighting a passage of text and having a shortcut that will automatically create a page with a name that shows where it came from and copying the path to the clipboard would be fantastic (so that I can just go to the referer page and paste the reference).
However, the only issue left would be how embedding is displayed. In Roam, I can put a block reference inline with other annotations. In Obsidian, references take their own line and disrupt the outline of the page. If it was possible to choose to make an inline embed, it’d be great.
12 Likes
the only issue left would be how embedding is displayed. In Roam, I can put a block reference inline with other annotations. In Obsidian, references take their own line and disrupt the outline of the page. If it was possible to choose to make an inline embed, it’d be great.
Good point, and a good solution. Mind making a separate feature request for this so that the devs can see? If not, I can do it!
4 Likes
Having been thinking about document possibilities, my preferred solution would be:
- Select text with option to make it a separate linked document - right click or keyboard shortcut
- To accommodate the possibility of multiple overlapping links, to have a forward links pane
- To avoid too many [[s to simply underline the text that is linked
- And put a list of the forward links somewhere out of sight such as YAML front matter, so that the integrity of a pure document system is preserved.
I think this could even be done as a plugin since it only automates functionality that is already present.
It’s also infinitely flexible.
To perfect zettelkasten usage, the initial name for the new linked notes could be the date/time stamp.
I know that some have argued in favour of long documents, but Roam works in blocks - they’re just hidden in the presentation of a single document.
2 Likes
Well the ideas in this thread have convinced me - after working a while trying them out I’ve come to the conclusion I can accomplish my goals using the ability to transclude headers in Obsidian without additional block addressability. It has a little more friction than I’d like but not so much that it impedes my workflow. Given that the markdown centric approach is a key value point in my adoption of the tool it seems I need to accept the tradeoff…Thanks for all the great discussion - the community associated with Obsidian is a great reason to be excited about where the tool is headed.
9 Likes
Just a small correction: Obsidian is not specifically, or only, a zettelkasten app. It is a note-taking app that can be used as a zettelkasten if one desires it, but it is not a sine qua non.
I have been referring to some outspoken Zettelkasten (or, rather: atomised notes) supporters in this thread/forum and did not intend to imply that Obsidian had to be - or was only allowed to be - used in such a fashion.
OK, I misunderstood you. My apologies.
2 Likes
+1 on this feature request. There might be a way to make this happen now with a lot of custom CSS.
6 Likes
We need block refers (un-editable) , also need block embed ( editable) – this is roam style.
but in Obsidian, we hope block refers ( editable) , block refers ( un-editable) with refers child block .
1 Like
I thought exactly the same! The plaintext structure of Obsidian gives it some more freedom, instead Roam is “blocked” in blocks. It could happen that you have a quite long block of text, but you want to reference only a small part of it. With the “snippet” way you said, you could do it. I also made two pics explaining how it could be.
Basically you start writing inside the two brackets and a windowed search tool appear (I screened the left bar search tool), showing you all the pages containing what you wrote and a little preview of it
When you find your “block”, you start highlight it and the window lets you easily (but how easily is questionable, for sure not so easily for long sentences) highlight all the text of that page
When you have finished highlighting, you could press Enter and the “snip reference” is created. How? This is a programmer question, and I am not. I think that it is possible to use the ID way that Roam uses. The program could put some unique symbols around the referenced text. For example: ^^^IDSTRING|text^^^. The program would know that everything inside | and ^^^ would be the text, and everything inside ^^^ and | would be the ID of the reference. And if you move to another note taking tool in the future, you can clean your markdown files from these tags simply by deleting everything that is inside ^^^ and | (it should be like a Regex command, right? I’m not a developer).
One problem is that this would be not easy to implement in a WYSIWYG editor
1 Like
I can imagine this will hard to do as long as .md files are “the database”. Roam surely is storing text very differently in its Datomic database.
From my experience with Roam what would I like to see “as a compromise” in Obsidian?
Linking to headlines is working. Headlines are parsed from the .md text and taken as anchors. That makes sense. (If the filename changes, links are updates. If the linked to headline changes, links are not updated, though. Quite understandable with .md files being the “database”.)
Headlines stick out with their # xyz at the beginning of a line.
How else could a paragraph (Roam “block”) be identified in a text file? By its line number - which is very volatile. Not good. Or by its first characters. Roam does identification with an internal block id; but Obsidian could rely on the user like it does for headlines.
If headlines can be presented during linking after the # so could any paragraph in an .md file. And if I continue typing I can narrow down the relevant paragraphs. Maybe I start parapgraphs I want to link to with a tag? Or I start them with a special § title of my own?
Gospel of Mathew
Chapter 1
…
The Birth of Jesus
§18 Now the birth of Jesus Christ took place in this way. When his mother Mary had been betrothed to Joseph, before they came together she was found to be with child of the Holy Spirit;
§19 and her husband Joseph, being a just man and unwilling to put her to shame, resolved to divorce her quietly.
§20 But as he considered this, behold, an angel of the Lord appeared to him in a dream, saying,…
Whatever is as the beginning of a paragraph can be used as a links - until it’s unique. [[Gospel of Mathew#§18]] would be sufficient in this case.
But in this case:
Humpty Dumpty sat on a wall.
Humpty Dumpty had a great fall.
more than just the first word would need to be included in a link, e.g. [[Poem#Humpty Dumpty h]] to reference the second paragraph. (Note that there was not special character needed at the beginning of the paragraphs. They were used in the prev example just to make selection of “linkable paragraphs” easier.)
Another option is to limit all your notes to the one paragraph/block. A new keyboard shortcut to add a sequential note, and a display set so that the notes appeared sequentially on screen in separate panes.
Unfortunately that requires users to adjust to a different concept of what they are writing. Some people organise their writing in a similar way in Scrivener which displays the separate sections with a feint line between them.
2 Likes