Paragraph+List Block Transclusions: Making 'ranges' less fragile

[ryanwwest]

Hi there, I recently made a FR that is very related to what this plugin provides, and thought to share it here: https://forum.obsidian.md/t/paragraph-list-block-transclusions/69841. Quoth looks very neat and I may use it to solve my issue (I especially love the inline vs. embed rendering) but the fact that embed link 'blocks' might break if you edit the source material (based on ranges: "start of para" to "to the end") might make it too fragile for me (similar to the headings-link updating problem)).

I was wondering if the author might have any insight on how to solve this or if there is a way to use Quoth with a less fragile selection method than ranges to prevent breakage if you modify the source. For example, having Obsidian-like start/end range markers like ^abcdef or ^q-abcd which are already rendered tiny to be out of the way but are more recognizable and thus not as likely to accidentally delete (and also indicators that this text is/was referenced).

[erykwalder]

You could use comments as deliminators, although in live mode they might show up more than you'd like, but in preview mode and in the quoth it'll render nicely.

Alternatively, the ranges field can be ommitted entirely if you have a precise enough block/heading selector.

But adding ranges by blockid might not be a bad feature. I'll keep this open for now.

[ryanwwest]

Thanks @erykwalder. I had a further thought about the idea of ranges by block-id, but it might not fit into your vision with Quoth. I was wondering if, assuming this FR were eventually implemented using blockid, it could be easily extended to support a slightly more concise/native format such as this:

![[note#^beginning_^end]].

I use _ because Block identifiers can only consist of letters, numbers, and dashes so there would not be conflicts. Granted, you could not specify Quoth fields unless an additional syntax were added like perhaps ![[note#^beginning_^end|key:val]] which is probably unnecessary—just fall back on the verbose codeblock method if you need specific configuration over your defaults.

[erykwalder]

I probably won't ever add shorthand. For one, markdown processing in obsidian isn't the easiest. Or I'm not sure if even possible, since that syntax would still get picked up by the regular embed processor. But also, for two, it adds all kinds of edge cases and exceptions.

[notuntoward]

Would obsidian's fairly subtle built-in block ID's work? The ones with carat symbol (^) ?

This seems more robust, more stock obsidian, and would partially address #2