Should org-link-parser add type "file" when link has no "file:" prefix?

Should org-link-parser add type "file" when link has no "file:" prefix?

[Joseph Turner]

Hello!

I expect the following to return "[[/foobar]]":

(with-temp-buffer
  (delay-mode-hooks (org-mode))
  (insert "[[/foobar]]")
  (goto-char (point-min))
  (let ((link (org-element-link-parser)))
    (org-element-link-interpreter link nil)))

Instead, it returns "[[file:/foobar]]".

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:

https://git.sr.ht/~ushin/hyperdrive.el/tree/33d8cef0507fbbe25839a019b5c42fda862ac4de/item/hyperdrive-org.el#L137

In org-transclusion.el, org-element-context is used to parse a link, and
then org-element-link-interpreter is used to insert it into a buffer:

https://github.com/nobiot/org-transclusion/blob/b10d4de93c6c0523bd4e7e72c11ef3a9a5630370/org-transclusion.el#L372

The problem is that the "file" protocol prefix is added to links which
have no protocol prefix.  When you call org-transclusion-make-from-link
with point on "[[/foobar]]", org-transclusion.el ends up inserting this:

#+transclude: [[file:/foobar]]

which, at least with hyperdrive.el, doesn't point to the same file as

#+transclude: [[/foobar]]

All suggestions are welcome!

Thank you!!!

Joseph

Re: Should org-link-parser add type "file" when link has no "file:" prefix?

[Ihor Radchenko]

Joseph Turner <joseph@ushin.org> writes:

> I expect the following to return "[[/foobar]]":
>
> (with-temp-buffer
>   (delay-mode-hooks (org-mode))
>   (insert "[[/foobar]]")
>   (goto-char (point-min))
>   (let ((link (org-element-link-parser)))
>     (org-element-link-interpreter link nil)))
>
> Instead, it returns "[[file:/foobar]]".

Thanks for reporting!
Fixed, on main.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=d15e52fef

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

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.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Should org-link-parser add type "file" when link has no "file:" prefix?

[Joseph Turner]

[-- Attachment #1: Type: text/plain, Size: 2593 bytes --]

Ihor Radchenko <yantar92@posteo.net> writes:

> Joseph Turner <joseph@ushin.org> 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


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: org-current-uri-scheme-follow.patch --]
[-- Type: text/x-diff, Size: 1051 bytes --]

diff --git a/lisp/ol.el b/lisp/ol.el
index 20aab6bb8..3808b9215 100644
--- a/lisp/ol.el
+++ b/lisp/ol.el
@@ -1097,12 +1097,15 @@ (defun org-link-open (link &optional arg)
       ;; first need to integrate search option, if any.
       ("file"
        (let* ((option (org-element-property :search-option link))
-	      (path (if option (concat path "::" option) path)))
-	 (org-link-open-as-file path
-				(pcase (org-element-property :application link)
-				  ((guard arg) arg)
-				  ("emacs" 'emacs)
-				  ("sys" 'system)))))
+	      (path (if option (concat path "::" option) path))
+              (f (org-link-get-parameter org-current-uri-scheme :follow)))
+	 (if (functionp f)
+             (funcall f path)
+           (org-link-open-as-file path
+				  (pcase (org-element-property :application link)
+				    ((guard arg) arg)
+				    ("emacs" 'emacs)
+				    ("sys" 'system))))))
       ;; Internal links.
       ((or "coderef" "custom-id" "fuzzy" "radio")
        (unless (run-hook-with-args-until-success 'org-open-link-functions path)

Re: Should org-link-parser add type "file" when link has no "file:" prefix?

[Joseph Turner]

[-- Attachment #1: Type: text/plain, Size: 372 bytes --]

Joseph Turner <joseph@ushin.org> writes:
> - 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')

Please ignore the last patch - this one checks for a "file:" prefix.

Joseph


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: org-current-uri-scheme-follow-2.patch --]
[-- Type: text/x-diff, Size: 1127 bytes --]

diff --git a/lisp/ol.el b/lisp/ol.el
index 20aab6bb8..947576ddb 100644
--- a/lisp/ol.el
+++ b/lisp/ol.el
@@ -1097,12 +1097,16 @@ (defun org-link-open (link &optional arg)
       ;; first need to integrate search option, if any.
       ("file"
        (let* ((option (org-element-property :search-option link))
-	      (path (if option (concat path "::" option) path)))
-	 (org-link-open-as-file path
-				(pcase (org-element-property :application link)
-				  ((guard arg) arg)
-				  ("emacs" 'emacs)
-				  ("sys" 'system)))))
+	      (path (if option (concat path "::" option) path))
+              (f (org-link-get-parameter org-current-uri-scheme :follow)))
+	 (if (and (not (org-element-property :type-explicit-p link))
+                  (functionp f))
+             (funcall f path)
+           (org-link-open-as-file path
+				  (pcase (org-element-property :application link)
+				    ((guard arg) arg)
+				    ("emacs" 'emacs)
+				    ("sys" 'system))))))
       ;; Internal links.
       ((or "coderef" "custom-id" "fuzzy" "radio")
        (unless (run-hook-with-args-until-success 'org-open-link-functions path)

Re: Should org-link-parser add type "file" when link has no "file:" prefix?

[Ihor Radchenko]

Joseph Turner <joseph@ushin.org> 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/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.

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:/README.org]] 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:
https://list.orgmode.org/orgmode/c98a38b0-6dea-4b5c-b00f-a39ea922537f@app.fastmail.com/

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Should org-link-parser add type "file" when link has no "file:" prefix?

[Joseph Turner]

Ihor Radchenko <yantar92@posteo.net> writes:

> Joseph Turner <joseph@ushin.org> 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.

Thanks!  Are you suggesting something like [[file+hyper:/README.org]] ?

>> 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.
>
> 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">.

> 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">.

>> 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:
> 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)

Thank you!!!

Joseph

Re: Should org-link-parser add type "file" when link has no "file:" prefix?

[Ihor Radchenko]

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.

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

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

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

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Should org-link-parser add type "file" when link has no "file:" prefix?

[Joseph Turner]

[-- Attachment #1: Type: text/plain, Size: 3829 bytes --]

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:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-lisp-ol.el-org-link-open-Use-let-bound-follow-functi.patch --]
[-- Type: text/x-diff, Size: 969 bytes --]

From 0c83446f16441df39618e43f964e18f672205d55 Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Mon, 15 Jan 2024 00:24:30 -0800
Subject: [PATCH] lisp/ol.el (org-link-open): Use let-bound :follow function

---
 lisp/ol.el | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lisp/ol.el b/lisp/ol.el
index 779175403..9bc2f5fb0 100644
--- a/lisp/ol.el
+++ b/lisp/ol.el
@@ -1125,9 +1125,9 @@ (defun org-link-open (link &optional arg)
 	   ;; argument, as it was mandatory before Org 9.4.  This is
 	   ;; deprecated, but support it for now.
 	   (condition-case nil
-	       (funcall (org-link-get-parameter type :follow) path arg)
+	       (funcall f path arg)
 	     (wrong-number-of-arguments
-	      (funcall (org-link-get-parameter type :follow) path)))))))))
+	      (funcall f path)))))))))
 
 (defun org-link-open-from-string (s &optional arg)
   "Open a link in the string S, as if it was in Org mode.
-- 
2.41.0


[-- Attachment #3: Type: text/plain, Size: 20 bytes --]


Thank you!

Joseph

Re: Should org-link-parser add type "file" when link has no "file:" prefix?

[Ihor Radchenko]

Joseph Turner <joseph@ushin.org> writes:

>>> 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
> ...
> This is similar to the way .git/objects/ directories are structured.
> ...
> Does that answer your question?

Not really.
May you please provide an example with an Org file containing file links
and how you envision to transform them? Will they be transformed
depending on the directory the Org file is located in?

>>> (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)

You are right.
What we can do then is pass an extra argument to :follow function - the
link object. That way, :follow function can get all the information it
needs.

> By the way, I think this minor improvement could be made at the bottom
> of org-link-open:
>
> From 0c83446f16441df39618e43f964e18f672205d55 Mon Sep 17 00:00:00 2001
> From: Joseph Turner <joseph@breatheoutbreathe.in>
> Date: Mon, 15 Jan 2024 00:24:30 -0800
> Subject: [PATCH] lisp/ol.el (org-link-open): Use let-bound :follow function

Thanks!
Applied, onto main; I added TINYCHANGE cookie to the commit message.
https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=0254854ee

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Should org-link-parser add type "file" when link has no "file:" prefix?

[Joseph Turner]

Ihor Radchenko <yantar92@posteo.net> writes:

> Joseph Turner <joseph@ushin.org> writes:
>
>>>> 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
>> ...
>> This is similar to the way .git/objects/ directories are structured.
>> ...
>> Does that answer your question?
>
> Not really.
> May you please provide an example with an Org file containing file links
> and how you envision to transform them? Will they be transformed
> depending on the directory the Org file is located in?

I don't want to transform the file links.  The idea is that an Org file
"foo.org" could be copied into a hyperdrive, and [[./bar.org]] would
point to a file called "bar.org" in the same folder in the hyperdrive.

That way, you could copy both "foo.org" and "bar.org" from your local
directory into a hyperdrive, the links between them would work as-is.

Pseudo-code for a hyperdrive.el :follow function for file: links:

(defun hyperdrive--org-file-link-follow (url &optional _prefix _link)
  (when hyperdrive-mode
    (hyperdrive-open
      (hyperdrive-convert-path-to-hyper-url url option)) ;; Turns "/foo" into "hyper://PUBLIC-KEY/foo"
    t))

(org-link-set-parameters "file" :follow #'hyperdrive--org-file-link-follow)

>>>> (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)
>
> You are right.
> What we can do then is pass an extra argument to :follow function - the
> link object. That way, :follow function can get all the information it
> needs.

I like this idea!  Would this change break existing :follow functions
which only expect max two args?

>> By the way, I think this minor improvement could be made at the bottom
>> of org-link-open:
>>
>> From 0c83446f16441df39618e43f964e18f672205d55 Mon Sep 17 00:00:00 2001
>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>> Date: Mon, 15 Jan 2024 00:24:30 -0800
>> Subject: [PATCH] lisp/ol.el (org-link-open): Use let-bound :follow function
>
> Thanks!
> Applied, onto main; I added TINYCHANGE cookie to the commit message.
> https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=0254854ee

Thanks!

Joseph

Re: Should org-link-parser add type "file" when link has no "file:" prefix?

[Ihor Radchenko]

Joseph Turner <joseph@ushin.org> writes:

>> May you please provide an example with an Org file containing file links
>> and how you envision to transform them? Will they be transformed
>> depending on the directory the Org file is located in?
>
> I don't want to transform the file links.  The idea is that an Org file
> "foo.org" could be copied into a hyperdrive, and [[./bar.org]] would
> point to a file called "bar.org" in the same folder in the hyperdrive.
>
> That way, you could copy both "foo.org" and "bar.org" from your local
> directory into a hyperdrive, the links between them would work as-is.
>
> Pseudo-code for a hyperdrive.el :follow function for file: links:
>
> (defun hyperdrive--org-file-link-follow (url &optional _prefix _link)
>   (when hyperdrive-mode
>     (hyperdrive-open
>       (hyperdrive-convert-path-to-hyper-url url option)) ;; Turns "/foo" into "hyper://PUBLIC-KEY/foo"
>     t))
>
> (org-link-set-parameters "file" :follow #'hyperdrive--org-file-link-follow)

You do not really need Org mode to do this. Instead, it may be
sufficient to define a file handler in order to make things work
"magically". Check out 26.12 Making Certain File Names "Magic" section
of Elisp manual.

>> What we can do then is pass an extra argument to :follow function - the
>> link object. That way, :follow function can get all the information it
>> needs.
>
> I like this idea!  Would this change break existing :follow functions
> which only expect max two args?

No. We can preserve backwards-compatibility by checking :follow function
arity and only passing the extra argument with the :follow function
supports that many arguments.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Should org-link-parser add type "file" when link has no "file:" prefix?

[joseph]

January 17, 2024 at 5:15 AM, "Ihor Radchenko" <yantar92@posteo.net> wrote:



> 
> Joseph Turner <joseph@ushin.org> writes:
> 
> > 
> > > 
> > > May you please provide an example with an Org file containing file links
> > > 
> > >  and how you envision to transform them? Will they be transformed
> > > 
> > >  depending on the directory the Org file is located in?
> > > 
> > 
> >  I don't want to transform the file links. The idea is that an Org file
> > 
> >  "foo.org" could be copied into a hyperdrive, and [[./bar.org]] would
> > 
> >  point to a file called "bar.org" in the same folder in the hyperdrive.
> > 
> >  That way, you could copy both "foo.org" and "bar.org" from your local
> > 
> >  directory into a hyperdrive, the links between them would work as-is.
> > 
> >  Pseudo-code for a hyperdrive.el :follow function for file: links:
> > 
> >  (defun hyperdrive--org-file-link-follow (url &optional _prefix _link)
> > 
> >  (when hyperdrive-mode
> > 
> >  (hyperdrive-open
> > 
> >  (hyperdrive-convert-path-to-hyper-url url option)) ;; Turns "/foo" into "hyper://PUBLIC-KEY/foo"
> > 
> >  t))
> > 
> >  (org-link-set-parameters "file" :follow #'hyperdrive--org-file-link-follow)
> > 
> 
> You do not really need Org mode to do this. Instead, it may be
> 
> sufficient to define a file handler in order to make things work
> 
> "magically". Check out 26.12 Making Certain File Names "Magic" section
> 
> of Elisp manual.

Thank you!  I've added a note to look into that: https://todo.sr.ht/~ushin/ushin/168#event-288786

> > 
> > > 
> > > What we can do then is pass an extra argument to :follow function - the
> > > 
> > >  link object. That way, :follow function can get all the information it
> > > 
> > >  needs.
> > > 
> > 
> >  I like this idea! Would this change break existing :follow functions
> > 
> >  which only expect max two args?
> > 
> 
> No. We can preserve backwards-compatibility by checking :follow function
> 
> arity and only passing the extra argument with the :follow function
> 
> supports that many arguments.

Good to know.  If the goals of hyperdrive.el can be accomplished without adding complexity to Org mode, it may be best to avoid avoid adding another argument to :follow functions.  WDYT?

> -- 
> 
> Ihor Radchenko // yantar92,
> 
> Org mode contributor,
> 
> Learn more about Org mode at <https://orgmode.org/> https://orgmode.org/%3E .
> 
> Support Org development at <https://liberapay.com/org-mode>, https://liberapay.com/org-mode%3E, 
> 
> or support my work at <https://liberapay.com/yantar92> https://liberapay.com/yantar92%3E
>

Re: Should org-link-parser add type "file" when link has no "file:" prefix?

[Ihor Radchenko]

joseph@ushin.org writes:

>> > > What we can do then is pass an extra argument to :follow function - the
>> > >  link object. That way, :follow function can get all the information it
>> > >  needs.
>> > > 
>> > 
>> >  I like this idea! Would this change break existing :follow functions
>> >  which only expect max two args?
>> > 
>> 
>> No. We can preserve backwards-compatibility by checking :follow function
>> arity and only passing the extra argument with the :follow function
>> supports that many arguments.
>
> Good to know.  If the goals of hyperdrive.el can be accomplished without adding complexity to Org mode, it may be best to avoid avoid adding another argument to :follow functions.  WDYT?

I did not make any changes to Org mode. And I will not, unless we need
to pass this extra information to :follow functions.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Should org-link-parser add type "file" when link has no "file:" prefix?

[joseph]

February 1, 2024 at 4:23 AM, "Ihor Radchenko" <yantar92@posteo.net> wrote:



> 
> joseph@ushin.org writes:
> 
> > 
> > > 
> > > > > What we can do then is pass an extra argument to :follow function - the
> > > 
> > >  > > link object. That way, :follow function can get all the information it
> > > 
> > >  > > needs.
> > > 
> > >  > > 
> > > 
> > >  > 
> > > 
> > >  > I like this idea! Would this change break existing :follow functions
> > > 
> > >  > which only expect max two args?
> > > 
> > >  > 
> > > 
> > >  
> > > 
> > >  No. We can preserve backwards-compatibility by checking :follow function
> > > 
> > >  arity and only passing the extra argument with the :follow function
> > > 
> > >  supports that many arguments.
> > > 
> > 
> >  Good to know. If the goals of hyperdrive.el can be accomplished without adding complexity to Org mode, it may be best to avoid avoid adding another argument to :follow functions. WDYT?
> > 
> 
> I did not make any changes to Org mode. And I will not, unless we need
> 
> to pass this extra information to :follow functions.

Thank you!  I think we can close this issue.  Can I close the issue myself?

> -- 
> 
> Ihor Radchenko // yantar92,
> 
> Org mode contributor,
> 
> Learn more about Org mode at <https://orgmode.org/> https://orgmode.org/%3E .
> 
> Support Org development at <https://liberapay.com/org-mode>, https://liberapay.com/org-mode%3E, 
> 
> or support my work at <https://liberapay.com/yantar92> https://liberapay.com/yantar92%3E
>

Re: Should org-link-parser add type "file" when link has no "file:" prefix?

[Ihor Radchenko]

joseph@ushin.org writes:

>> I did not make any changes to Org mode. And I will not, unless we need
>> 
>> to pass this extra information to :follow functions.
>
> Thank you!  I think we can close this issue.  Can I close the issue myself?

Sure.
Handled.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>