Block Reference for multiple paragraph

Resolved help
#1

Add a syntax like

:::
paragraph 0.

paragraph 1.
::: ^block_id

to support more flexible block reference.

Maybe it will also influence a block style solution like annotation syntax:

::: .danger
DONT divide any number with ZERO!
::: ^DivZeroError

Or use two same block id to sign up a block:

^abc

Paragraph.

ABC

^abc

Use case or problem

The existing block reference syntax looks like

Paragraph. ^block1

Paragraph 2

^block2

But I want it support two or more paragraphs, such as a formula and its explain

:::
$$
E^2 = m^2c^4 + c^2 p^2
$$
+ $E$ energy
+ $m$ mess
+ $p$ momentum
+ $c$ speed of light
::: ^EinsteinFormula

Proposed solution

I have using quote block to make them into one block element:

> $$
> E^2 = m^2c^4 + c^2 p^2
> $$
> + $E$ energy
> + $m$ mess
> + $p$ momentum
> + $c$ speed of light

^EinsteinFormula

But it use a dirty semantic.

Current workaround (optional)

This syntax inspired by pandoc’s markdown.

Related feature requests (optional)

5 Likes
Block referencing - Custom length of Parent and Child in list
Block referencing with a equations
#2

This is already perfectly possible.

A block is any lines with a blank line before and after them. So,

Some paragraph.
Another paragraph.
A third paragraph.
^someblockID

will create an addressable block with all three paragraphs.

#3

When i test, the formula is treated as 1 block. Each bullet is treated as 1 block. So totally 5 blocks.

It also doesn’t work when i indented the bullets.

#4

If you want to do more complicated multi-component “block” references, use a heading reference instead. Here’s a demo:

Screen Shot 2020-10-28 at 11.07.12 AM
Screen Shot 2020-10-28 at 11.07.12 AM1736Ă—1236 187 KB

I can move this back to #feature-requests but I don’t think it will ever happen, because heading references are the same thing.

2 Likes
#5

I think the heading is great for this case. Thank you for your examples!

1 Like
#6

I think it would be great to move this into feature request. Semantically, a heading is a different thing and, on a minor note, a heading prints to the screen unlike a block id.

Going even further, I’d rather have blocks to be any collection of consecutive lines where “consecutive” means that the collection does not contain any blank lines and is delimited by blank lines. This is consistent with these structures printing as paragraphs in TeX or Markdown where line breaks are indicated by explicit blank lines.

For lists, where one would want the items to be referencable, one could give all options in the auto-complete menu: The whole list (if its items are not separated by blank lines) and surrounding text (if, again, not separated by blank lines from the list items) and each item itself.

Could this behavior be implemented by plug-ins in the future or is it to fundamental to the inner workings of Obsidian?

2 Likes
#7

Do you agree with the OP’s proposal?

#8

It would certainly be a helpful feature I think.

But what I’m more interested in is making post number 2 of this thread (your post) defaultable behavior (i.e. introduce a global setting for this), i.e. let the auto-complete menu show consecutive non-blank lines as blocks (rather than each single line).

Should I do a dedicated feature-request for this? Thanks!

#9

Ah, I think I’m confused—that already is the default behaviour. See my example screenshot above, the “First Block”. If you keep three lines together, they’ll be treated as a block together.

#10

Sorry, you’re right!

What I was confused about is that this behaviour breaks down for new lines starting with the character “-” (lists) or “$” (for Latex math formulas).

I guess, now, that this is also intended behavior, but I would really like

We have proven that
$$1+1=2.$$

to be a single block. Also I’d like to be able to refer to a list as a whole as a single block.
Could there be settings for this?

Maybe, for lists, the auto-complete menu could first show only whole lists and the list items in a submenu whenever the list entry is active. This would also declutter the auto-complete menu.

#11

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?

#12

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.

1 Like
#13

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?

#14

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!

1 Like
#15

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.

2 Likes
#16

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.

2 Likes
#17

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
#18

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
#19

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
#20

We are in agreement @Dor :slight_smile:

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.