I couldn’t find anything similar to this idea. Please point me to a discussion If I might have missed it.
As of now, Obsidian supports 4 default settings for how to handle new attachments that for example get dragged and dropped into a note.
One can specify whether file attachments like images or pdfs should be stored …
- (all) in the root folder of the vault,
- (all) in one specific folder,
- in the same folder of the
note.mdto which the attachment gets added newly, or
- in a new specific attachment subfolder relative to the folder that contains said
There are pros and cons for all four of those settings.
Commonly, people that choose 3 and 4 want to keep notes and attachments relatively close together on a file system basis. One reason could be logical separation of different topics, another ensuring easy data-portability in case the entirety of the note base has to be broken up in the future.
If you have a couple of hundred notes with attachments either globally in the vault or in the respective attachment subfolders those can get messy rapidly.
All in all, I find Obsidian’s attachment handling (especially for in-line image embeds) not as intuitive as most other note-taking applications handle it. Most (Evernote, Bear, Apples Notes, OneNote, etc.) store the attachments “in the file” itself, which therefore becomes a container or package file. The example that everyone probably knows are the files embedded inside a
.docx. Such behavior is not (yet) offered by Markdown natively.
However, I do fully understand that using Markdown as a plain-text markup language imposes certain limitations. And I can also see that some users embed attachments in multiple documents and will therefore find having a central attachment folder more useful than this proposal. Those options (1-4) should not be taken away, of course.
Yet, for me, this is a rare a use-case, and if so I would prefer to use transclusions to the parent note that contains the attachment instead.
Since embedding all attachments in-line in the file itself (for example base64-encoded) is also not practical and breaks compatibility I would propose a fifth option to handle attachments:
If a file (image, pdf, etc.) is dragged into a
note.md file in Obsidian the attachment should not be saved in a dedicated attachments folder as per the current options. Instead the
note.md should be moved into a corresponding subfolder itself, which acts like a container:
note.md/note.md. All embedded attachments of this note will then be stored in this very parent folder as well.
So instead of …
(The example uses option 2 with a specified global attachments folder.) vault/ ├── attachments/ │ ├── document for note1.pdf │ ⋮ │ ⋮ (many more attachments) │ ⋮ │ └── image for note2.png ├── note1.md ├── note2.md ├── note3.md ⋮ ⋮ (many more notes) ⋮ └── note9000.md
… I propose:
vault/ ├── note1.md/ │ ├── document for note1.pdf │ └── note1.md ├── note2.md/ │ ├── image for note2.png │ └── note2.md ├── note3.md ⋮ ⋮ (many more notes with and without attachments) ⋮ └── note9000.md
note1.md/is a folder that just carries the same name of the only contained note file,
note1.md. The folder name includes the Markdown file extension
.md. This is for the sake of consistency and to allow for easy differentiation to user-created folders (no .md suffix) and as a requirement for the related features below.
If a note gets renamed, both, the note and the folder name should be kept in sync in the file system.
Folders, which’s names end in
.mdshould not be sorted atop in Obsidian’s file explorer, but instead be treated like any other regular note. Clicking on it should open the contained note directly.
However, a file explorer context menu option could be added to temporarily expand the note like a folder in the file explorer if the user wants to reveal the attachments that way. Yet, the contained
note.mdremains hidden at all times to avoid confusion. Due to the note being tied to its
note.md/-folder and vice-versa this is also not necessary.
.md-folders should also not appear as folders in the picker when creating backlinks, as well as in the outgoing links or backlink palettes, nor in the quick open dialog. Currently the
.mdfile extensions of note files get omitted. Just like that the automatically created parent folder’s
.mdname suffix is also never shown in the UI. Generally the
.md/-folder and it’s contained
.md-note are treated like a single entity.
Example: Instead of …
… it should be displayed as follows.
Please note: The image attachment is displayed as a direct child of the note in the quick open dialog. The
.mdsuffix of the folder name is hidden and so is the contained note file
This direct parent-child relation of parent note (folder) and attachment is significantly more useful than having all attachments end up in generic, (global) attachment folders.
This becomes especially evident in this example:
In contrast, with the attachments stored in the
noteX.md/-folder of the corresponding parent note, additional information about the relation is conveyed. Especially for large vaults with extremely high note and attachment counts this relation becomes a useful way to structure the knowledge base.
However, the user should additionally have the option to move an attachment “out of” the initial parent note and into a chosen location like a global attachment or any other manually created folder if desired. Just like it is possible right now. For example if the user already knows that an attachment will be referenced from multiple notes this could be handy. A simple context menu option could be provided to move the when right-clicking on the image or other attachment.
This suggestions core idea, the aspect of treating the note’s automatically created
note.md/-folder and its contained note file (
note.md) should be carried out through the whole UI. That includes the wiki-style links for example:
Therefore instead of …
[[note2.md/note2]] or ![[note2.md/screenshot B.png]]
… the links are just displayed as follows inside of Obsidian, while the actual Markdown document (file system basis) contains the embeds as shown above for compatibility reasons:
[[note2]] or ![[note2/screenshot B.png]]
I am fully aware that this might seem like a hacky workaround to the problem that Markdown doesn’t offer file-embedding natively at first. Yet, so are the current options with more or less central attachment folders.
This proposed solution is fully compatible with any Markdown viewer to maintain 100% data-portability. Yet, it increases overall user experience and especially user convenience by treating dragged and dropped attachments more like traditional note-taking apps do. The main feature suggestion is that Obsidian would automate the creation of the note’s parent-folder and cover up the redundancy of the naming scheme by treating both, the folder and the contained note, as one entity throughout the entire UI.
I’d love to hear your thoughts on this idea that has percolated since I first Obsidian and experienced the friction regarding attachments.
Thanks a lot in advance.