#1

With the advent of block references the case for atomic notes is less strong in that one can link to blocks of text/paragraphs.

Put another way, each block of text is, in effect, an atomic note. It can be further identified with a hashtag and/or info such as author.

3 Likes
Auto-update block references when target block is moved to another note
#2

Yes, but keeping links updated is way more brittle with code blocks. Move them around and the links break, while using file names and aliases always stay updated if you keep using atomic notes.

1 Like
#3

@anon41901724: file names stay updated, I agree, but I don’t know about aliases, while headers definitely do not stay updated.

I don’t understand why you mention code blocks, unless you mean block references. If that’s the case, moving a referenced block of text around in the same note should pose any problem since the link to it references the ^ number.

I don’t see why one would change a ^ number anyway.

Headers are another story: like file names they can and do get changed. If I am not mistaken Licat has said that, some time in the future, links will be made to update with header name changes too, like with file names.

So, in fact, headers are the only weak link (pun intended) in the chain, at this stage.

#4

Apologies, I did mean block references. If you move that block in another note, the link is broken (since it’s referenced by the note name first [[file^block]]). Aliases however do not break since they use the base alias syntax anyway : [[file|alias]]

Change the file name and it updates; remove the alias in the note’s front matter and nothing is broken since Obsidian has inserted it anyway in the note text. That’s why we were a few pushing for this in the Discord dev channel :slightly_smiling_face:

Of course, if you never move your blocks from any note, all is fine, but I’m discovering that overusing block references implies additional maintenance when refactoring notes.

I completely support the idea that headers should update as they change, of course. That’s indeed the missing link.

1 Like
Round trip-note with headings>note with embeds in a click and/or simultaneous
#5

@anon41901724: changing a header name and leaving it within its original note is a sine qua non for links to update, I would have thought. But moving a header and the text below it to another note will not update links either, or will it?

As for “overuse” of block references implying additional maintenance when refactoring notes, I agree. I had not thought about that. I am a very enthusiastic user of block references, esp. transcluded ones. And I do have long notes that I refactor (using the plug-in for that), so I will have to pay attention to that.

Having said that, transclusions, whether of headers and their sections or of block references, for me are a very important feature compared with other markdown note-taking apps. During refactoring I will have to manually update links - nothing is perfect in life.

2 Likes
#6

You’re totally right, moving stuff outside of a note does imply refactoring no matter what. But I have started using block references and transclusions with wild abandon, like you do, and I found myself forced to do lots of manual updating. Which is kind of a case for atomicity, at least in Obsidian and if you refactor often.

#7

@anon41901724: true, too much manual updating warrants atomicity. OTOH, if blocks of text are considered as “atomic” notes (I am trying not to get too nuclear :sweat_smile:) then the case for refactoring becomes weaker.

Of course one does not want a note to become too long (though I have some running 5-600 lines), so rather than adding new info to that already long note one could create a new note. That way one can keep block referencing and keep refactoring within acceptable limits.

My inclination is to go that route, rather than reduce block referencing. Of course, I am not block referencing for the sake of it, but I do find it gives cleaner transclusions than header-based ones.

I appreciate this discussion with you because it stopped me in my tracks, made me think again, and discern a way forward without having to reduce or give up block referencing.

1 Like
#8

I’m glad it gave you good food for thought! :grinning: also made me think on my end, so thank you too!

1 Like
#9

@anon41901724: :+1:

1 Like
#10

Appreciate this discussion. I believe there is fertile ground ahead for block references, but needs maturation.
My literary workflow is to bring the complete list of annotations into my vault into one file. I had tried to use blocked refs to highlight evernote potentials, but it became a bit overwhelming regarding graphing and mind mapping; not to mention atomicity. What I have found that works great is the plugin Extract Highlights. This allows me to select notable snippets and then have them extracted into their own notes with a link intact to the source. Sorta the best of both worlds.

#11

Following on from my last comment to you, and looking back at this comment you make, I can now report that when I was faced with a long note in which many blocks have been transcluded in other notes, I decided against refactoring, or rather, refactoring the bits that weren’t transcluded.

So, yes, block references are great, but to be used in moderation.

1 Like