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.
@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.
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
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.
@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.
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.
@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 ) 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.
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.
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.
I’ve found myself using headers to organize actual information contained within a note, and only using block references (apart from footnotes, which stay with their own notes for obvious reasons), in a few specific use cases, to reference information that doesn’t exactly reside within a note at all.
I have a couple thousand blog posts that I don’t want to copy into my vault, but sometimes want to be able to acknowledge exist and are relevant to certain topics, and a good deal of writing I did for school which, likewise, I don’t want to just go back and copy over.
So I have a note for each year of blog posts that just lists them:
…and a note for each college, listing my assignment topics under each course, and I add block references when I want to be able to say, “see here: I wrote a paper/blog post about that,” and that way I know to go find it if I want it.
I have no reason to think these will ever be broken apart because they don’t contain any real information of their own.
Even with all the advantages block referencing provides and ignoring all the arguments against it, a case can still be made for using Atomic notes in Obsidian.
Many of us are actually looking for an infinite white board which affords capturing of thoughts in more than textual way and inter linking these. With Excalidraw that is now a reality.
Having atomic notes allows dragging and dropping them in Excalidraw white board. Surely, one can embed blocks but it’s not as fluid as drag drop.