I use the “strange new worlds” plugin and it’s buggy. As with anything software, the first 80% is the easiest; the last 20% is the hardest. Once “strange new worlds” actually gets out of beta and gets used by many people to iron out edge cases, then it will be worth bringing up to argue how hard or easy it would be for core to implement this stuff.
1 Like
What version are you on? Been updating it almost daily. But yeah, still in its experimental phase but as of recent days very stable.
1 Like
I strongly support the suggestion to enable inline block references.
And I have an additional, related request:
If I’m in an outline and I reference a block from another outline, the bullet point from the referenced block is included so I get two bullet point symbols where the reference is inserted (clumsy formulation, but the screenshot should illustrate it). It would be great to have the possibility to exclude the bullet point in the block reference.
3 Likes
I never said it would be easy. In fact, I said:
My point was merely that if TfTHacker could implement a huge part of the functionality (and I don’t have any bugs so personally, I’d say in a quite stable way) in a relatively short time, then:
- It’s certainly possible to implement (I mention this because people often bring up that Obsidian is not block-based, implying that that makes it impossible to implement functionality like this. But this plugin demonstrates that it is possible and it doesn’t cause a slowdown.
- I think much of the groundwork has been laid for the devs to use this plugin as a starting point for integrating this stuff into obsidian or its API
1 Like
The distance between what you are pushing for and the original intent of this feature request is large. I can see an argument for in-line block rendering being generally useful. The rest, making SNW part of core? Not so much.
Since (the yet unreleased) SNW doesn’t do what this FR is asking (or at least I didn’t see it) but it does several other things such as (https://forum.obsidian.md/t/add-markers-for-headings-and-blocks-that-are-referenced-somewhere-else/37708), I suggest to move the convo related to SNW to this thread in plugin ideas https://forum.obsidian.md/t/viewable-links-to-block-reference/12564/.
3 Likes
Yes I agree that an inline view showing references to a block, header or link is not germane to the original post.
So I’ll just say that on this topic, it would be fantastic to have embeds that look and feel as realistic and native as possible.
That means for me:
- Some indication that an embed is present is ok with me, as long as it isn’t super distracting. Like if it has a border or an icon in the gutter
- Beyond that though it shouldn’t be too distracting
- It definitely should be usable inline
- If used in a list, ideally, it would not create a blank line and new indentation as it does now, but rather would fit into a list as an item (with children) on the bullet point where the embed is located. It should have the same level of indentation as the embed, and its children should be indebted appropriately further.
- It should not use radically different styling or cause whitespace to be padded around the embed
To me, a transclusion indicates that an idea is meant to live in more than one place. It’s to prevent copy pasting. So to me it should be absolutely usable inline or as part of a list or list of tasks
9 Likes
This is spot on imo
1 Like
Any updates from the Obsidian team on this?
Ideas and thoughts happen at the block level, the node.
When creating new ideas we often reference many nodes from many other pages. True block level support is huge missing feature from Obsidian.
I’m attempting to use LoqSeq and Obsidian on the same markdown files but it’s not ideal and pretty frustrating.
If Obsidian simply copied the LogSeq implementation of inline block references, it would be the dream (this is btw the same implementation Roam does). Note that they have built this on top of markdown files too.
7 Likes
100% agree with this. This feature would help obsidian get more adoption (and respect) from the greater world of PKM apps. There are whole new startups forming around this simple idea, like Tana.
6 Likes
+1 would like to see something similar to logseq where you can mirror blocks inline, for me its a must feature that obsidian is missing
2 Likes
I feel like with recent updates to Obsidian we actually went further away from block embeds being inline (as flowing text).
I had a CSS hack that got around this problem, but that stopped working. Looking at the HTML generated by Obsidian, a lot of other stuff got added (a title div for the block) and so on.
I would say this proposal is effectively dead.
7 Likes
I feel there is no interest at all to work on this. Asked this some weeks ago in the Discord (inside channel) but without any response from the devs. I don’t know… I feel strange about this 
2 Likes
This quote hits at the heart of the matter for me. Each transclusion (instantiation) object has a different intent and usage; each with its own implied metadata.
I suspect the rendering (display) is trivial but the effect on the street warrants pondering. In my interaction with other PKM users, there’s only a small group of us that use block references. Obsidian is poised for huge influx of users in the short term. The bang for the buck may not be there presently.
Block references have taken on new meaning, for me, with the introduction of the canvas plugin. Gonna give this quote and thread some thought today. Great fodder here. Happy new year!
8 Likes
Would be sad indeed if inline embeds were not on the map anymore.
The devs of Make.md figured out a way to have editable block embeds - I wonder if it’s so hard to have them rendered inline.
Btw. TfT, if you manage to make your inline css work again, would you mind sharing it?
7 Likes
- So I thought about and messed in Obsidian with notes, cards, and groups on canvasses with internal links of all permutations.
- Notes and Links to Notes are first class citizens because they have inheritance and metadata or properties exposed to the UI.
- We don’t appear to have much, if any property values defined and exposed for Obsidian internal links (also commonly called section and block links or simply, block references).
- We could certainly css our way to some sort of short term solution, but we need persisting things like an optional foldable link title (ideally for each separate transcluded embed). The pipe Display Text item on a WikiLink for internal links seems appropriate (it is a known bug) and associated rendering properties for appropriate css.
- The link title, for me, should render as a hover when cursoring over the embedded linked text in the manner discussed above in this FR.
- Fully first class would be able to edit those internal embeds in the same manner we edit their parent note.
- Since there are no standards in this area across the PKM realm, migration of data both into and out of Obsidian is a huge issue with regard to where we go with section and block references. There is much discussion about the function and appearance of how block references work on other PKM tools, but none of the various link structures are cross PKM compatible in the underlying interface api and syntax.
- A happy ending. I have been hesitant in the past to use internal links until the last couple days; lets face it, they are messy and lacking and for final output, they suck. I now use them whole heartedly because even with their limitations, they be incredibly handy for research and drafting efforts in my vault. For now, I’ll continue to export from Obsidian into Scrivener for submissions.
- And that is all ok. Besides, I have faith our developers, both core and community plugin folks, will get us to link utopia.
5 Likes
I second this feature!. It would be really benenficial if it were implemented. This is my only gripe with Obsidian! 
4 Likes
It is very sad if this is truly the case 
2 Likes
I would also love this feature!
3 Likes
… a big +1 for this feature!
2 Likes