Scalable alternative for "Shortest path when possible"

Use case or problem

Currently using “Shortest path when possible” option for new links results in neither absolute nor relative, but a “global” path being used, meaning if there is a file with the same name somewhere, the link will point to it. Doesn’t matter if it’s in the same folder or 10 folders away.

Issues:

  1. If I want to create a new file by simply creating a link and following it, I can’t do so if a file with such a name already exists, I will simply be directed to the existing file.
  2. I can’t create links that use a relative path when it’s shorter than the absolute one.
  3. I can’t create links that use an absolute path when it’s shorter than the relative one.
  4. If there is a name collision (such file already exists), the absolute path will be used even when the relative one is actually the shortest one.
  5. Say I have several folders inside my vault root (let’s call them root folders), currently I simply don’t have an option to tell obsidian “Hey, I want you to use relative paths for children pointing to each other inside each root folder (since relative paths are much likely to be shorter), but if they want to point to a different root folder, feel free to use absolute path if it’s shorter than the relative one.”
  6. Using “Absolute path in vault” will in 99% of cases result in unnecessarily verbose links unless I specify an alias.
  7. Using “Relative path to file” will result in ../../../../../../../../../../../something where a simple dev/something can get the job done.

Proposed solution

Rename “Shortest path when possible” to “Unique filename when possible” or something like that to properly define what the option does and add an option like “Shortest absolute or relative path” that does just that, uses only absolute or relative paths.

This should basically be the same thing VSCode has as “shortest” option under “Preferred path style for auto imports” (except for aliases since we don’t have any, so simply absolute or relative paths inside the vault).

Using this new option will allow us to create more meaningful paths, which in most cases would allow us to simply move independent folders (folders that don’t rely on content outside them) between vaults.

Current workaround (optional)

Manually specifying paths in the desired format. Not really a workaround since the feature is directly responsible for creating links in the first place.

Note: I’m frustrated and it’s 3 AM so if I’m not making sense somewhere I would be happy to expand/rephrase

1 Like