Allow the omission of `file:` when external linking for special cases.

[sg1fan]

Does this feature exist in Emacs orgmode core?

Yes

Orgmode link

External Links

Feature value

No response

Additional context

From the link above:

As a special case, “file” prefix may be omitted if the file name is complete, e.g., it starts with ‘./’, or ‘/’.

For example, [[file:./book/notes.org][notes]], [[file:book/notes.org][notes]], and [[./book/notes.org][notes]] are all equivalent external links. However, [[book/notes.org][notes]] would be an internal link.

I'm currently unable to follow links of this form. For better compatibility with existing org-mode files, I think this type of link should be allowed.

[jgollenz]

Am I correct in the assumption that ./ and / are the only two cases that this is possible?

edit: looks like it from the examples further down

[jgollenz]

Actually, the external links should work already. Do neither of them work for you? What about [[/absolute/path/to/book/notes.org][notes]].

[sg1fan]

With further testing, I see that it works when the path is relative the org root directory. This is not compatible with the emacs implementation. The link is relative to the file containing the link. I believe this is how markdown does it too (since it doesn't necessarily have any notion of a root directory, unless you're using something like Obsidian).

[sg1fan]

I actually realized that nvim-orgmode also doesn't have any setting for the org file directory, which led me to realize that the links are relative the nvim's cwd. So if I'm in the parent directory of the buffer's file, the relative link works.

Edit: I just checked the emacs implementation and that is, to my surprise, how they do it too! So I guess this is already implemented, but what is interfering with my usability experience was my usage of the projects.nvim plugin. My mistake.

[sg1fan]

In my opinion, I still think the link should not be calculated based on nvim's cwd. The emacs implementation can get away with it because every time you visit a link, the working directory changes. Moreover, the project root and the current working directory are independent, so commands work as expected.

For nvim, the working directory doesn't change when visiting links, so plugins that search for files (like fzf/telescope) work as expected. However, the relative links inside the file will not work unless you change your directory to always match the parent of the current file, which interferes with normal nvim workflows. Moreover, links of the form [[file:book/notes.org[notes]] seem to work differently from links of the form [[./book/notes.org][notes]] inside of nvim-org. That is, from my testing, the [[file:book/notes.org][notes]] link will calculate the path based on the current file, while [[./book/notes.org][notes]] will calculate the path based on nvim's cwd. Hence, I suspect that this is a bug.

And lastly, the org file specification most certainly has no notion of current working directory since it is a file format that is supposed to be independent of emacs. The fact that emacs does this isn't relevant, in my opinion, because they always assume emac's cwd is always the parent of the buffer's file. This assumption does not hold inside nvim.

[jgollenz]

So what does the specification actually say on that issue? Should links be calculated relative to the path of the current buffer or relative to some org-directory

[sg1fan]

To be complete, we can say there are three possibilities for calculating relative links: the editor's cwd, the file's parent directory, or org-directory. We know for certain it is not org-directory because emacs doesn't do this. Additionally, the org syntax is exactly that, just syntax without any notion of org-directory. When the manual references org-directory, this is probably just an emacs-specific implementation detail.

So the question is whether it is the editor's cwd or the file's parent directory. I argue that it should not be the editor's cwd because the file format should be completely independent of any such notion. The fact that emacs does this, in my opinion, is coincidental based on assumptions that hold inside that editor.

[jgollenz]

I can't reproduce the behavior you experience. This is what I created:

root/
  root.org
  test/
    test.org
    nested/
      nested.org

with

-- root.org
[[file:./test/nested/nested.org]]

-- nested.org
[[file:../test.org]]

-- test.org
[[file:../root.org]]

This loop should not be possible, if the cwd of the editor was taken. Am I missing something? I can confirm that the editor's cwd does not change and that the buffers indeed have the path I would expect them to have.

[jgollenz]

Oh well, it breaks when I omit the file:. There we go. We actually already use the correct strategy, but not when we omit the file:.

[jgollenz]

My example is flawed. It doesn't say that ../ is a case that allows for omission of the file:. This should work:

root/
  root.org
  test/
    test.org
    nested/
      nested.org

-- root.org
[[./test/test.org]]

-- test.org
[[./nested/nested.org]]

-- nested.org
* success

but doesn't. I'm working on it.

[sg1fan]

../ actually is a case that it allows. It wasn't mentioned explicitly in the list of examples, but this link type definitely works.

[kristijanhusak]

These issues should've been solved with the recent refactor. If the problem persists, please open up a separate issue.