Ihor Radchenko writes: > Joseph Turner writes: [...] > Thanks for reporting! > Fixed, on main. > https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=d15e52fef Thank you for the quick fix! >> In hyperdrive.el currently, "[[/foobar]]" and "[[file:/foobar]]" have >> different meanings: a link with no protocol prefix, like "[[/foobar]]", >> points to a file inside of the same hyperdrive (virtual p2p folder), >> whereas a link with the "file" protocol prefix, like "[[file:/foobar]]", >> points to a file on the local filesystem: > > I do not recommend such approach. From the point of view of most of the > Org mode code, it makes no difference whether file link has file: or > not. So, you may face unexpected issues. You are certainly right about unexpected issues ;) > It would be more reliable to provide a separate link type. > We might even extend the special file+application: link type syntax that > already allows special behavior for opening file links. Thank you! Would you explain about extending file+application syntax? hyperdrive.el does add a separate "hyper://" link type which is used to link to a hyperdrive file or directory by its "full" URL: hyper://aaj45d88g4eenu76rpmwzjiabsof1w8u6fufq6oogyhjk1ubygxy/hyperdrive/hyperdrive-manual.org Additionally, we want to make it possible for users to copy ("mirror") a directory of Org mode documents into a hyperdrive for other users to view and link to. Ideally, when users upload a set of files to a hyperdrive, the relative and absolute links between those files within the same hyperdrive work without modification. We also wanted users to be able to link to files on the local filesystem from within a hyperdrive. Firefox and Chrome treat prefix-less links as pointers to files on the same webserver and "file:" links as pointers to files on the filesystem. We thought that we could do the same thing in hyperdrive.el: [[/README.org]] could point to a file in the same hyperdrive while [[file:/README.org]] could point to a local file. Would you be open to changing Org mode so that prefix-less links could be handled in a special way by certain modes? Here's an idea: - Add a buffer-local variable `org-current-uri-scheme' which could be set to a string like "hyper". - When handling "file" type links, check if `org-current-uri-scheme' matches one of the keys in `org-link-parameters', and use the appropriate handler instead of the "file" handler. (see attached patch for an example usage in `org-link-open') What do you think? Thanks!! Joseph