I moved a couple of posts into this new thread because they propose a very general way of defining ranges. General is nice but sometimes complex if the problem at hand is narrow.
11 Likes
The syntax for transclusion of range should allow to Exclude first (or last) block/item mentioned in specification of the range.
This would allow to keep adding items to start or end of (sub)list …
… without need to update specification of each transclusion of this (sub)list.
usecases:
- content of the chapter without header
- queue/stack of tasks
- nested (sub)lists
syntax suggestions
- I suggest double period as distinct range specifier. “
..” has minimum of other common meanings so it would intuitively explain itself at first glance to many computer literate people. Wikipedia: Ellipsis (computer programming) → Ranges -
![[FileNameORPageURL#^id1..^id2]]transcludes range starting by block with^id1and ending by block denoted by^id2. - Assuming that IDs do not start by hyphen, start/end item would be excluded from the range by prefixed hyphen.
-
![[pageurl#-^id1..^id2]]excludes first block from range so items inserted after^id1are automatically transcluded without need to update references. -
![[pageurl#^id1..-^id2]]excludes last block from range so items appended to list before^id2are automatically transcluded without need to update references.
related requests/functionality:
- Header level support for Linking To/Embedding Ranges
- Add Ranges To Header-Level Embeds
- Transclude Range of Blocks
- Date/number ranges within search/filter
- Support sub-list embedding
- Text Fragments
- Preferably many of these would be solved by one consistent syntax.
13 Likes
- The same as in the post above would work for html elements with id attribute (without caret). e.g.
![[pageurl#id1..id9]],![[pageurl#-id1..id9]]. - References to “markdown” block-id and html id can be combined in ranges.
![[pageurl#^md-block-id..div-id]] ![[pageurl#span-id..-^md-block-id]] - If there can exist/exists element with ID starting by hyphen then we would need e.g. to enclose such ID in parentheses in order to exclude it from range.
-
![[pageurl#-(-id-starting-by-hyphen)..id2]]. - This approach is suggested for negative numbers in Date/number ranges within search/filter
-
Interfering problem:
Reference to chapter is indistinguishable from reference to html block and (perhaps as a consequence) it is impossible to transclude / refer to html block/element with assigned ID.
For example [[pageurl#markdown-chapter-id]] refering to
# Markdown Chapter ID
Text of the chapter.
is indistinguishable from [[pageurl#span-id]] refering to html span
markdown text
containing<span id="span-id">html elements</span>
which is standard but does not work in Obsidian.
solution:
I would suggest (before Obsidian 1.0) changing syntax for chapter reference from [[pageurl#markdown-chapter-id]] to [[pageurl##markdown-chapter-id]].
- This would put markdown headers with associated chapters on the same level as (markdown)-block-IDs with associated blocks.
First#symbol would always separate fragment from page URL and the second#would denote header just like^denotes block. Then we could refer to everything:
![[pageurl#html-element-id]]
![[pageurl##markdown-header-id]]
![[pageurl#^markdown-block-id]]
![[pageurl##first-chapter..#last-chapter]]
![[pageurl#-#intro-chapter..#last-chapter]] where prefixed hyphen excludes introduction chapter from range.
![[pageurl##intro-chapter..-#index-chapter]]
![[pageurl##first-chapter..]] transclusion starts by first chapter up to the end of page.
![[pageurl#-#intro-chapter..]] everything after intro chapter up to the end of page.
![[pageurl#..#last-chapter]] everything up to last chapter (including)
![[pageurl#..-#last-chapter]] everything up to last chapter (excluding)
Possible behavior of references in nested structures:
- useful e.g. for referencing Bible
- Distinguish duplicate id’s via tree structure created by chapters, markdown blocks and html elements
![[bookname##ch1^v5..#ch2^v3]]- from chapter1/verse(block)3 up to chapter2/verse3 - limit range by boundaries of surrounding (higher level) block/element:
![[pageurl##chapter1..^block-in-chapter1]] would transclude beginning of chapter up to specified block. ![[pageurl#^block-in-chapter1..#chapter1]] would transclude end of chapter starting by specified block.
11 Likes
I created a related FR today and later realized that this FR could solve it, and wrote about my particular use case for it there: Paragraph+List Block Range Transclusions. It lists plugin Quoth that also supports transcluding ranges, which might be a temporary solution for those interested until this FR is implemented.
1 Like
Earlier I wrote my suggestions in comments under Header level support for Linking To/Embedding Ranges - Feature requests - Obsidian Forum before I discovered this topic.
Just linking here for now. I can post it here as well if needed.
I tried to propose a syntax that is both more flexible and readable compared to other proposals I can see.
_Update: the other topic seem to be merged here, so my suggestion is now available further down this thread: A general format for specifying links to a part of note (multiple paragraphs, ranges) / Embedding Multiple Consecutive Headings Or Blocks - #63 by KillyMXI
1 Like
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)
- Custom length of Parent and Child in list may be solved with the same method.
20 Likes
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.
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.
If you want to do more complicated multi-component “block” references, use a heading reference instead. Here’s a demo:
I can move this back to Feature requests but I don’t think it will ever happen, because heading references are the same thing.
3 Likes
I think the heading is great for this case. Thank you for your examples!
1 Like
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?
6 Likes
Do you agree with the OP’s proposal?
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!
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.
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.
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