For all open vaults, enable cross-vault use of [[internal links]]. The internal links from one vault to another would be active and clickable as long as the “destination” vault is open. If that vault is closed, then the link would not be clickable. If the destination vault is closed perhaps Obsidian could display a tooltip message such as Vault <valult> is not available, or something like that.
I realize having a feature that would “break” if the right combination of vaults is not open is suboptimal, but the current work-arounds of having to set up obsidian:// URLs is also sub-optimal. The feature I’m suggesting utilizes Obsidian’s rapid linking feature, and I assume Obsidian can be aware of the open vaults in the environment. Correct me if I’m wrong.
Current workaround (optional)
Use obsidian:// file path or Advanced URI (plugin) links.
Related feature requests (optional)
I didn’t find any, but I wouldn’t be surprised if others more knowledgable or adept than me have debated this feature at length.
Getting an Obsidian URL from A to paste in B is more steps than typing [[note name...]] and letting Obsidian do auto-find/complete.
Linking to #headings and ^blocks with URLs is even more complex.
If the destination note moves, the URL can break.
Obsidian tries to suggest strings within Obsidian URLs as “unlinked mentions” – this is partially avoidable, but not optimal.
Using the Advanced URI plugin with the UUID feature (i.e., the plugin finds the UUID in frontmatter) is a bit easier, and avoids the “note moved” issue, but still extra time spent flipping back and forth between vaults to grab and paste the URL.
For many reasons that I cannot change, I work between at least two vaults that are always open. “Internal linking” between them would be wonderful.
I don’t think that will ever be possible.
Obsidian exists within its vault. Anything outside is just files folders etc - even if they are sometimes vaults.
Only option would be nesting the vaults and doing the linking from the new top vault, which would be able to see all the files in both vaults. However, I suspect that, even if that were feasible for you, that your usage would cause problems.
Well, maybe. Maybe not. It’s software. The software can be aware of what’s in the open vaults.
And, perhaps, feasibility is a developer consideration. No harm at all in wishing.
I always feel “feature requests” in a user forum is a way for users to explain their wishes. Assessing what the developer can or cannot do is well beyond our pay grades, maybe. I would love to hear what licat or silver think.
Anyway, I mentioned above that I’m fully aware that if the vault at the other end of an internal link is closed, then the internal link would be broken. I accept that shortcoming.
I agree it is just software and wishes are welcome. There could be possible solutions. For #1, for example, it might be interesting to have a fuzzy-matching URL generator that can read all your open vaults, and make it easier to create a URL by searching.
For #3 I can’t see this being avoided. I certainly wouldn’t want anything I do in one vault to automatically change any aspect of another vault without my explicit consent. Especially if the vault was not open. And like you already pointed out, it could be inconsistent depending on whether it is open or not.
#4 Someone else flagged this as a feature request, and I personally think it could be considered a bug. I hope that gets fixed, or as an option to make it not suggest or change those links.
The symlink is a good idea. This is great because it utilizes the file system feature. It is maybe not as portable if you look on cross-plattform like Windows to Mac or iOS and Android.
Does anyone have experimented with this?
We (part time or full time) Windows users might get an interesting option with Windows 11 and next generation “Windows Subsystem Linux” (WSL)
TODO:
NOTE: