This is fair, but I think it’s non-trivial. Is there a really good reason you wouldn’t just make a subheading for this mixed-item block you want to use?
I am mainly using Obsidian for documenting my mathematics research, and it is seldom that an equation stands on its own without being embedded in a full sentence. So, I find my autocomplete menu to mostly show broken-up phrases with equations splattered in between which is not really ideal…
Experience with mathematical texts shows that “$”-characters do not delimit blocks of thought such that I think Obsidian should not break blocks around them. One could still use blank lines to indicate equations standing on their own.
For lists I am not really sure. If it is difficult to also keep list items referencable at the same time then maybe the current behavior is acceptable.
2 Likes
Definitely not! Are inline equations, like in this sentence ($2+2+5 iff the 2s are really big$) split by the block parser? Or is it just that “bigger” equations that stand on their own are separated? Or, option three: do most mathematicians write all equations on a separate line?
Maybe there’s an argument that math should never be considered its own independent block…
The trick will be, I think, figuring out how to parse a “mixed block.” To which point, we must ask: what kind of syntax makes sense? The OP proposed a delimiter (specifically :::). Is this approach the best approach?
No, inline equations are not split (fortunately). While inline math equations arguably appear more frequently, display math equations (as the big equations are called in TeX terms) are pretty frequent, too.
It is bad form to let equations stand on their own and not embed them into full sentences. One finds almost never exceptions to this in the literature.
I think the best way would be to just not treat “$$” (the delimiters of display math) as a delimiter of blocks just as “$” is also not treated as a delimiter of blocks.
Then,
We are interested in the set
$${x\in\mathbb{R}\colon a\leq x\leq b}$$
which is just the interval $[a,b]$ containing all numbers between $a$ and $b$.
would be a single block (as it should be), while
Euler’s identity:
$$e^{i\pi} = -1$$
Continuing, …
would make the equation a distinct block as could sometimes be intended.
Display math mode should be used whenever printing the formula centered and big makes things more readable. Nonetheless, the mathematical content is still part of its enclosing paragraph whether or not it is printed inline or big.
Thank you for your patience!
2 Likes
These requests are simply for users to be able to define the beginning and end of blocks rather than have them always set by predefined rules.
If you use headings as headings, then they’re not the best answer for this.
It may not be a common need, but it seems to me a simply defined request that would suit a number of users.
I think that the minute that block references were added to Obsidian, the question of exactly how blocks should be defined was up for discussion and requests.
This is the sort of thing where markdown syntax breaks but was always possible with old fashioned markup.
6 Likes
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.
3 Likes
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.
2 Likes
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.
1 Like
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).
1 Like
We are in agreement @Dor 
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.
The autocomplete menu shows three different blocks.
Why could that be? I am not really sure what the rules are anymore.
Thanks again!
I am looking for exactly what OP requested. Any solution since October?
2 Likes
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.
Is there a solution for this?
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 ![[]].
Sorry, I don’t follow. Do you have an example?
Thanks for putting that together. It is still a little hard to follow, but I think I understand.
You want to include two or more blocks in one embed without showing a header. This is possible: hide the header from your embeds via a CSS snippet. See Theme: Obsdn-Dark-Rmx (now with Light & Dark) - updated 2020-09-11 - #9 by Klaas.
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.
2 Likes
@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.
2 Likes