I am reminded of the excellent work by @Pseudonium on the Obsidian to Anki script. To summarize a series of posts from that long thread, it developed over time to include different methods of defining what a “block” of text is as far as that script is concerned.
It started out as predefined markers - literally START and END - but has progressed to being able to use headings and the text following them as well as custom regex expressions to let you define what constitutes a “block”.
I think I agree with @Dor in the sense it feels like there is room for advancing the definition of a block from the current single method to something more diverse, potentially all the way to allowing custom definitions.
I found my way to this thread via chatter on Discord and now that I’ve caught up a little further on there, I realise I haven’t really furthered the discussion!
Indeed a block could be defined differently, but why should such functionality be introduced? I did not consider the latter, and unfortunately OP, I do not have a use case to weigh on the for argument.
When you’re familiar with something it’s easy enough to imagine new features and functionality for it. Whether or not the effort involved in bringing those to life is worth it needs to be considered under the light of actual usage.
Without the constraint of having to describe how a bell or whistle could be used, everybody is capable of imagining a bell or whistle.
If sufficient people have use cases, or there are particularly important use cases for a smaller number of users.
The reason for keeping feature requests and having people support them or not allows this to be gauged. For that it needs to be in feature requests.
I understand the maths use, and I can envisage others. Makes little difference to me because I don’t use block references (I’d probably approach a similar need with many short notes and embedding), but I appreciate the possibility that many might find this a significant enhancement for their own use of notes. And I’m not sure why it shouldn’t have a chance to garner support.
Thanks. I plan on moving the math bit of this thread out, and anyone who wants to offer another feature request for customizable block reference syntaxes can do so (following the forum template).
I refrained in my first reply from saying this whole post should be moved back to Feature Requests from Resolved Help. After more thought, and while writing my next post, I didn’t mention anything on that aspect again. I should have. I understand there are trade-offs a team needs to make when it comes to feature requests (vs “the current plan”) and that those particular trade-offs won’t exist if feature requests aren’t logged and considered.
The ever-understanding mod @ryanjamurphy has said he is going to extract the use case that has been described here into a feature request and that is great - I don’t even stand to nearly benefit from this yet I am excited! Many thanks, Ryan.
As for the original request, which I understand and appreciate, but do not have a specific use case for: I will also leave it for the OP or anyone else to make the case for.
Actually, as I was trying to construct a new thread to catch this use-case, I found out that it already works as you describe. The text you pasted is in a note on the left. A test note in Edit mode is on the top-right, showing the embedded block from the raw text. That note is Previewed in the bottom-right:
Thank you very much for this discussion! It seems that you are right again in my particular example, sorry about that! I should have checked that in advance.
But, as you can see in the screenshot below, this seems to not always be the case.
Yes, this feature would be great also for referencing blocks of paragraphs while keeping blank lines between them. For example, my current use case is to have templates for emails and I would like to compose different ones depending on the recipient. I don’t want a paragraph without blank lines, because I want to copy an email template ready to paste directly instead of adding each blank line.
But it could also be useful to have quickly readable composed notes.
Mmm, I think it is not enough. With alias I can’t change the real header if I make a ![]. I only can change how the link [] is visualized, but not the content if I make ![].
As for the second challenge, it’s true that the heading solution requires adding arbitrary headings to groups of blocks. I think you could create a “fake” header using e.g., H6s (######) that you hide in preview with CSS (e.g., h6 { display: none } as a workaround. Otherwise, you will have to wait until if-and-when this feature request is implemented.
@ryanjamurphy, having just searched for a solution to my problem (wanting to embed multiple blocks but not show a heading) I will try your work around for now.
Is there a feature request for manual defining of blocks that I can vote on? Thanks.
I totally support this feature request. The best would be the possibility to create nested and entrelaced blocks. For exemple, using the author suggestion
::: Block1
Line 1
::: Block2
Line 2
::: !Block1
Line 3
::: !Block2
Line 4
The result of
[[NoteName^Block1]]
Would be
Line 1
Line 2
And the result of
[[NoteName^Block1]]
Would be
Line 2
Line 3
Titles are not really aimed to create blocks. It’s interesting to have the ability to reference a title, but it can’t be considered as a block functionnality.
As proposed by the author, it could be possible to create a specific css class for the block, it could be interesting to share some style between notes.
I know there is a lot of feature to implement in Obsidian, and this one will be usefull for a small amount of people. But some people, like me, are really in need for this functionality.
On the referenced note, it should appear only one backlink. It’s impossible to do actually, we can’t use > nor titles because of the entrelaced blocks. We have to reference line by line the document. It’s a pain, it’s hard to maintain and it creates a lot of backlinks.
As proposed by the author, it could be possible to create a specific css class for the block, it could be interesting to share some style between notes. Obviously, for entrelaced blocks it should be tested, but it’s possible to add the classes and priority.
I 100% support for referencing multi blocks with a specific css class as @Showb said.
Sharing reference from notes to notes can be amazing. A simple but strong use case of it would be making resume. We might have various working as well as education experiences. We can spilt them into seperated markdown files. Now creating a targeted resume would be a few bunch of referencing.
I’m now refering them paragraph by paragraph, and then changing the refering style in resume. But there are some lines you would always refer(working duration, age, name, company name, etc), I wish there could be a customed block syntax/css class to wrap these blocks(lines), so I only need to refer them once.
Thank you!
By the way, if this is too complicated to implement, would it be better to choose a range for refering? For example, I got 4 blocks below to refer now, would it be possible to use something like [[notename#(^aaa,^bbb)]]?
I’m also in support of this feature, I specifically stumbled onto this thread trying to embed a list without having the random heading in the middle of my text as I would have to do it now.
I am particularly partial to OP’s second solution since it also provides the ability for nesting (as @Showb suggested) while still conforming to existing syntax, so with
Line 1
^aaa
Line 2
Line 3
Line 4
^aaa could continue to reference Line 1 while with
Line 1
^aaa
Line 2
^bbb
Line 3
^aaa
Line 4
^bbb
^aaa would reference
Line 2
Line 3
and ^bbb could simultaneously reference
Line 3
Line 4
I’d consider @CoreJa’s solution equally good, so for me it’d come down to which is easier to implement or which has the least edge-cases.
I don’t really have the time to implement this as a plugin atm, but I might if I find some. If someone else would care to do it, I’d be happy to contribute!
