#emacs #orgmode #attachment #files are really cool; they can allow me, eg, to attach the wav file of that crazy voicemail from my son to my journal entry for the day. The moment you do that, however, you are introducing application lock-in to your org file; future readings of the plain text cannot recover that attachment unless they are using orgmode, likewise git. I am probably still going to do it, though. But this is annoying.
🇳🇱
@worldsendless That just seems like a poor implementation, and contrary to how org-mode usually implements things... Why doesn it just have a text link to the relative location of the file?
@worldsendless @freemo isn't it based on node ID? Pretty sure I've configured it before to be based file title. I guess I don't find the ID based organization weird, but all of my org interlinking has been ID based for years already.
@nickanderson The strange thing is the added external concept of "node" as opposed to the regular linking of the actual files on your disk.
@worldsendless @freemo I guess I don't see it as an external concept. I called it node because that's the terminology used by org-roam for a note with an ID.
FWIW, mostly I have attachments go to a single directory organized under the ID but for some files I set the DIR property to a relative path and then new attachments are stored there./
For example:
#+property: DIR attachments/how-i-org-in-2023/
so those attachments are stored relative to that file.
@nickanderson very cool! I've also started using the TS stamping method (though I haven't actually attached anything for a few days)
@freemo that would be the typical non-attachment simple link. With attachments, a randomly named directory is created adjacent, and the filename is encoded/nomalized. Then the org file gets an `attachment`key added which includes said generated encoding.
I guess the benefit is that it is independent of the original file which could be trashed, modified, or deleted. But the indirect refactoring is a little strange.