It would be a really great workflow to for example use the new iOS app Highlighted, which allows to easily drag and drop highlights/quotes from for example Apple Books (and other readers) or even camera scanning of a physical book’s page with OCR transcription to capture and organize by book. It has an option to export those quotes as Markdown files.
If Highlighted would live reflect all new highlights and newly made changes to a Highlighted folder in iCloud, which contains live exported copies of all highlights of a books as flat .md files, it would be the perfect source for those “remote” (= not in the main vault folder) notes that contain quotes/highlights.
This approach would be very similar to how Noteplan stores its data or how GoodNotes and Notability offer live backup as a flattened PDF for reference.
Your expansive literature notes, conclusions and self-written summaries would be composed in Obsidian and put into context with other notes. The verbatim quotes from a book could then be transcluded from the book’s quotes/highlights source from the Highlighted folder. Due to Obsidian transcluding by headlines. It would even be possible to update the files maintained by Highlighted by even adding new quotes in between existing ones without breaking the Obsidian transclusions.
Wow, that would be the almost perfect workflow without redundancy, bouble-bookkeeping or copious amounts of copy/paste sessions.
I would like to know whether there’s plan for Obsidian to support relative path “…/”. I’m using Obsidian as part of a project. Please refer to the picture below, its a project folder hosted inside Google Drive File Stream.
For example in R, I can use R in my home computer, and in my lab. Because of the ability to use relative path, R can pull in data from another folder, and output in a different folder. And this is a consistent behaviour across computers.
Currently for Obsidian, if I put in a relative path, it will be converted into absolute path, and this can no longer be used in a different computer.
So, as a workaround. I decided to shift the vault into the project folder itself. Look at the screenshot below. Change a few settings, so that all new note, attachment or insert will go into the Obsidian folder.
The aftermath. Opening this vault took a hit in loading time. 20 seconds loading time compared to near instantaneous previously. I could not tell whether this is because there’s a lot of files, or because the project folder is in cloud.
I had thought of using the same structure but was concerned about performance. I posted a feature request to have a way to exclude folders from indexing other than the filenames or some variation. If we had that we’d also have portable vaults that can be mirrored to other systems and links would work.
The problem with relative links is that file:// URIs don’t support relative links.
That project is around 40,874 files right now. A quarter of them are pre-processed individual CSV files. A quarter of them are intermediary files used by an old plotting program. Half of them are png images that’s needed to be turn into animated GIF using an old program. They could be automated with R, but I have not needed to do it again right now to bother about it. I should probably do something about it soon.
The important scripts and documents are probably less than 500 files. Which is nice if I can tell Obsidian to not index some of the folders.
I know it’s off topic, which is why I didn’t ask more question about it.
I did try the “Excluded Files” option. Which excludes around 90% (roughly) of the files. There is no noticeable difference in the loading time. I did time (manually) before and after, around 20 seconds for both.
I suppose it depends on the purpose. For me, I mostly use transclusion of other files as a way of collecting files for viewing or export. If I want to prepare a file with many transclusions of files from all over the file system for export, I’d just start a new vault, use the plugin to add the files and delete the vault when I’ve done with it.
No. Only seems to import the file to embed and uses the wikilink format to do that.
Though I’m not sure why you would want to use an obsidian:// format rather than a simpler file lin - not that it makes any difference to embedding. The plugin doesn’t transcend Obsidian functionality, but it does give a convenient approach within Obsidian’s limits.
Though I’m not sure why you would want to use an obsidian:// format rather than a simpler file lin - not that it makes any difference to embedding.
Unlike file: links, obsidian: URLs would work even if the target vault is moved to another location (eg. onto an external volume). They would also work when the vaults are synced across multiple computers at differing file paths (eg. different volume names or user accounts). I am using the latter approach extensively.
All this assumes that the files are actually linked to, as opposed to being copied.