org mode link with just the non-directory part of the file name

Question

Is there a method to link files without specifying their absolute file name nor their relative file name; just the non-directory part of their file name? I remember stumbling into one when browsing the other day that was defined as a custom link type that maintains some sort of data structure that users can append to and that it is used to resolve links but the name escapes me.

so for example, to refer to a file located ../../blob.txt, all I have to do is [[LINKTYPE:blob.txt]] and this works across files. I would expect I need to add the absolute file name to some list/data structure or some other resolving mechanism.

Answer 1

You can use org-link-set-parameters to define your own link types as demonstrated in the following Elisp snippet.

The snippet contains a function my-org-open-file which opens the file given as org file link target. If the file name is relative and if the file with that name does not exist my-org-open-file tries to find an existing file by expanding the file name successively with all entries of the path list my-org-path.

Note that you can customize my-org-path. Just call M-x customize-option RET my-org-path RET and insert the paths you need.

If my-org-open-file does not find the file at all a buffer is generated with the original file name as buffer-file-name.

(defcustom my-org-path nil
  "List of paths to try with `my-org-open-file'.
If the LINK argument for `my-org-open-file' is a relative path
and a file with that path does not exist
try successively each of the directory entries of this list
as `default-directory' for expanding the path.
The directory entries can be given relative or absolute."
  :type '(repeat directory)
  :group 'org-link-follow)

(defun my-org-open-file (link)
  "Open LINK with `org-open-file'.
If LINK is given as relative file path also try to find file
with prefixes from `my-org-path'."
  (let* ((el (car (org-element-parse-secondary-string (format "[[file:%s]]" link) '(link))))
     (option (org-element-property :search-option el))
     (path (org-element-property :path el))
     (app (org-element-property :application el))
     (org-path (org-property-or-variable-value 'my-org-path t)))
    (when (stringp org-path)
      (setq org-path (list org-path)))
    (setq path (substitute-in-file-name path))
    (unless (file-name-absolute-p path)
      (cl-dolist (path-prefix org-path)
    (let ((try-path (expand-file-name path path-prefix)))
      (when (file-exists-p try-path)
        (setq path try-path)
        (cl-return)))))
    (apply #'org-open-file
       path
       (cond ((equal app "emacs") 'emacs)
         ((equal app "sys") 'system))
       (cond ((not option) nil)
         ((string-match-p "\\`[0-9]+\\'" option)
          (list (string-to-number option)))
         (t (list nil option))))))

(org-link-set-parameters
 "myfile"
 :follow #'my-org-open-file
 :complete #'org-file-complete-link)

You can set the search path also in the properties drawer of an Org section as demonstrated in the following example:

* My Section
:PROPERTIES:
:org-search-path: ("~/tmp" "/tmp" "/temp")
:END:

Answer 2

Late to the party, but I've just been wrestling with this myself. Just to be clear -- because the various edits and unedits to your question were a bit confusing -- I think what you were asking was, using well-established and widely-understood unix terminology:

Is there a way to link to a file by specifying only its basename; i.e. without having to also provide its dirname.

For example:

Is there a way to link to file /pugh/pugh/barney/mcgrew/blob.txt by specifying only blob.txt; i.e. without having to also provide, /pugh/pugh/barney/mcgrew

If that is what you were asking, then you can achieve a form of that by using Org's attachment: style of link. So where, in your question, you had:

[[LINKTYPE:blob.txt]]

you'd actually have:

[[attachment:blob.txt]]

Then when you did C-c C-o ('org-open-at-point') over that, Org would Just Figure Out what the "path" was to get to blob.txt.

The mechanism is that of org-attach, and specifically, org-attach using the ID method (as opposed to the DIR method). Using org-attach like that results in the following:

1. An ID property is created for the heading from which you want to link to your file
2. Then, based on that ID, an attachment directory is created
3. And then your file -- or a copy of, or link to, it -- is placed into that newly-created attachment directory
4. Finally, an attachment:-style link can be added to variable org-stored-links-p. You can then use org-insert-link, to insert something like [[attachment:blob.txt][blob.txt]] into the body of the heading in which you are working.

That's just a summary of how it works. It's slightly more complex in that there are a few other things that need to be in place to get it to work just as I've described. On the other hand, in practice it can be even simpler than I've described in that you don't even need step #4 if you don't want it. Org can figure out where the attached file is without that [[attachment:blob.txt]] link at all. It can actually get to and open your "attached" file just from the heading itself.

Now, cool and funky though all that is, the (potential) problem, given your specific question, is that although with this mechanism you get to leave it to Org to figure out where the linked file is located, the intention is that you also leave it to Org to decide where that location is in the first place. So you can't easily (although I suspect it's possible) do exactly what you have in your example, and just link to something like: ../../blob.txt. Instead, you'd find that you were linking to something like: ./data/20/221108T085858.791822/blob.txt. Of course it is usually the case that, as discussed, we wouldn't really care about that scary-looking filename, because we would be referring to that file as, at most, something like [[attachment:blob.txt]] or, even better, not at all and just relying instead on the implicit linkage between your file and the Org heading in question. But that is usually the case. Whether it applies in your specific situation, I can't tell.