Joseph Turner <> writes:

>> 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?

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.

> 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/
> 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: [[/]] could point to a file in the same
> hyperdrive while [[file:/]] could point to a local file.

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.

Why not make [[hyper:/]] use the "default" hyperdrive the
Org file belongs to.

> 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?

IMHO, it is too specific for Org core.
What we might do is allow setting :follow function for file: links. We
generally aim to remove hard-coded link types from `org-link-open',
exposing them to `org-link-set-parameters'.

For example, see WIP patch where we expose setting id: link properties:

Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <>.
Support Org development at <>,
or support my work at <>

Reply via email to