Ihor Radchenko <yantar92@posteo.net> writes:

> Joseph Turner <joseph@ushin.org> writes:
>
>>> See `org-open-file' IN-EMACS argument - we may use different handlers
>>> to open file links. Currently, IN-EMACS can be 'system or 'emacs. But
>>> nothing stops us from adding more options.
>>
>> Thanks!  Are you suggesting something like [[file+hyper:/README.org]] ?
>
> Yes.

Thanks - that could be useful.

>>> This will cause major issues when trying to export such links.
>>> Except for HTML export that utilizes `org-html-link-use-abs-url', but
>>> only for relative links.
>>
>> Yes, there are many users who rely on [[file:/index.html]] exporting to
>> <a href="/index.html"> instead of <a href="file:///index.html">.
>
> This is not what Org HTML export does. Only relative links are affected
> by `org-html-link-use-abs-url':
>
> Documentation
> Should we prepend relative links with HTML_LINK_HOME?
>
> Absolute links always remain absolute.

You're right.  I just meant that ox-html should keep the existing
behavior when exporting implicit file: links.  Many websites would break
if implicit file: links started exporting as <a href="/index.html">.

>>> Why not make [[hyper:/README.org]] use the "default" hyperdrive the
>>> Org file belongs to.
>>
>> I'd like for users to be able to take an existing directory of Org mode
>> documents and copy them all into a hyperdrive.  I think the least
>> surprising behavior is for the links between those files to continue
>> working.  Perhaps the best option is for hyperdrive.el to make all "file"
>> type links, explicit or not, point to other files inside the hyperdrive?
>>
>> In that case, there would be no way for Org mode files in a hyperdrive
>> to point to the local filesystem.  Similarly, when Org documents are
>> exported to HTML, there's no way to export <a href="file:///index.html">.
>
> May you please elaborate? How is hyperdrive directory different from
> local directory?

On disk, hyperdrive data is stored by hash prefixes like so:

/home/joseph/.local/share/hyper-gateway-nodejs/cores/
└── 00
    ├── 6a
    │   └── 006ae0628e1fad7c357fd4a1c6103d37bcb70797c6f0dba77c261871306b16b3
    │       ├── bitfield
    │       ├── data
    │       ├── oplog
    │       └── tree
    └── de
        └── 00de65a26162bbaad8f97bb89e81856ac1dd6a1bc10a46f06086b4a25b244ad5
            ├── data
            ├── oplog
            └── tree

This is similar to the way .git/objects/ directories are structured.

Of course, inspecting the storage directories of this kind with Dired
does not provide a meaningful UI.  Special software is required for
users to explore and open the hyperdrive "directories" and "files".

To push the git analogy further, the way hyperdrive-find-file is like
magit-find-file.  Both use an external program, git or hyper-gateway, to
pick out the correct data and present it to Emacs as if it were a file.

Does that answer your question?

>>> For example, see WIP patch where we expose setting id: link properties:
>>> https://list.orgmode.org/orgmode/c98a38b0-6dea-4b5c-b00f-a39ea922537f@app.fastmail.com/
>>
>> How would the :follow function for "file:" links get access to the link
>> search option?  IIUC, `org-link-open' handles "file:" links specially because
>> they require
>>
>> (org-element-property :search-option link)
>
> :follow functions are passed both path and search option.

How is the search option passed in?

IIUC in org-link-open, the path argument passed in has no search option:

(funcall (org-link-get-parameter type :follow) path arg)

By the way, I think this minor improvement could be made at the bottom
of org-link-open: