Wouldn’t it be easiest to have it function like this: User can highlight whatever and press a button which designate that as a block – that block gets stored as a dictionary<string, int[2]> where the string is the file name, and the two ints are the start and end point within the file.
Then the program just needs to have a list of such dictionaries to comb through?
Yeah, another markdown deficiency. Paragraph markers used to be normal, and exist still in word processors.
One easy syntax for a block ID which is consistent with markdown is to use ####### (h7). Markdown doesn’t process it as a heading. Some parsers do change the appearance (making size the same as h6), but it’s generally ignored, so wouldn’t interfere with functionality in other markdown programs. And easy to interpret because it follows a normal markdown syntax in a very similar role.
You’d have to do something to save having to count #s , but you have to do that anyway. I use a text expander.
I think its a bit more elegant than subverting h6, as has been suggested, as it doesn’t interfere with other programs, and documents prepared in other programs would still function as designed.
As with other headings, you’d either write a title or you’d make the whole block the ‘heading’.
@Dor: then what’s the difference with a regular heading?
The issue was to be able to link to smaller units rather than to paragraphs currently headed with a header, without having to put headers above single sentences.
You can write it all out in as small or large a chunk as you want. No need for a header. Or, if someone preferred, they could stick a title in.
Because it’s not a header, or any other recognized markdown syntax, the developers are free to parse it in any way they chose. They could have it as a block with no title or they could advise a title and parse it out.
The main thing is that it doesn’t clash with markdown but is a recognisable item for regular markdown users. And its appearance wouldn’t jar even in the source - one of their reasons for disliking an arbitrary UID.
@Dor: thanks for that explanation. To a non-geek Obs user that makes sense. Hopefully they’ll implement it, with or without a combination of some of the other solutions proposed here.
Thanks.
My own preference would be no title, and analysing sufficient characters in a block to achieve uniqueness. (Start with x and add 5 to that number when a clash was encountered.)
The big advantage of this approach is that it looks like markdown and doesn’t need a database. And hopefully that would be enough for Licat to be happy to incorporate it in the main program.
The disadvantage is that the extra processing would bring forward the point where the program slows.
I try to picture a solution that could be implemented manually. I like Christian Tietze’s way of thinking regarding automatic link suggestions in The Archive — something that we in Obsidianland take for granted.
More specifically, I try to adopt the Wizard of Oz experimental paradigm he mentions in the article: trying to break down the desired feature into steps that you could reproduce manually; doing it in a software agnostic way.
From this perspective, I think line numbers are too fragile: if you just count the lines until you find the referenced block and include that number in the referring text, you could end up with something like ((other file.md|42)) and that would work. But if you edit other file.md above the referenced block, line 42 wouldn’t be the right one anymore. Furthermore, lines wouldn’t allow you to reference sentences in the middle of a paragraph, for example.
I believe there should be some kind of identifier (be it a timestamp, a hash, a UUID or something shorter, etc.) and a syntax that defines the boundaries of the referenced block. And that reference should only be created on a per-need basis. So, in other file.md I’d have “Lorem ipsum ((wH473V3r|this right here is important)) dolor sit amet.” and reference it with ((wH473V3r)) anywhere I need to.
This would give obsidian all the info it needed to do its magic, like hiding IDs, replacing them with referenced text and synchronising changes. But, more importantly, it would allow anyone in the future to do it manually.
I think you’re right. There will be a lot of plugins to choose from and, as much as I’d like to believe I’d be able to code one of them, the truth is I’ll probably just benefit from someone else’s work. This is the limit of my contribution. I hope it helps, even if it’s only by fuelling the discussion.
That’s on point.
I am totally fine with block reference on the level of headings, and I’m looking forward to the mentioned improvements.
I actually find the approach to use files as blocks and to keep them short and snappy practicably superior to full block referencing since it somewhat forces one to put some thought into the note creation.
I think this is especially true in consideration of the awesome popover preview functionality and an extensive use of MOC’s.
With the additional flexibility of (fully functional) block reference at the level of headings, I can’t see much value in implementing a Roam like block structure at all.
When trying and looking into Roam, I even found it too atomic and too easy to get messy with.
This is a very important point IMO. Taking proper notes also means that I have to think more about what I want to state with this note. E.g., being forced to write a title for the note means that I have to come up with a short summary (or core statement) of what this note is about. IMO, performing this little extra step is truly helpful in the long-run, since it helps to increase the clarity of my notes, and sharpens my senses.
This is even more true for the act of “transcribing” the note’s thought with your own words in the comments of the note.
In addition, I think it’s important that I can reuse my notes in external applications. With block references, unless it‘s a software agnostic implementation, this may be tricky.
Also, what happens if you’d like to expand on a block, and convert it into a proper note? This likely would require the app to help you with converting all the links to the block into proper note links.
Block references are surely nice for quick reuse of little bits of text. But they should not replace the creation of proper atomic (& self-contained) notes. Long term, the latter will likely help you better to achieve structure & clarity in your notes archive.
@macedotavares This seems like a nice syntax! You might get it so that Obsidian auto-generates an ID in place if you don’t supply one, and this blends well with Obsidian’s existing piped link syntax - the part after the pipe is what you actually want to display. Might even allow nested blocks! Though I’ve no idea what use you’d have for that…
And as you say, it allows people in the future to do it manually too, even outside Obsidian - one could imagine writing a parser that generates a separate file for each block, with the title being the block name and the content being the block itself. So it’s portable too. It might even be as simple as just replacing ((block id|block content)) with [[block id|block content]] to generate a note.
Yep, I need this block! The block can help us link everything, besides, if this block can be collapsed and expanded it can be better!
Annuntio vobis gaudium magnum.
Habemus versus nexum.
This is in insider build now.
https://forum.obsidian.md/t/obsidian-release-v0-9-5-insider-build/7260
Could someone show me an example of this being used?
