* Should org-link-parser add type "file" when link has no "file:" prefix?
@ 2023-12-29 4:12 Joseph Turner
2023-12-29 14:49 ` Ihor Radchenko
0 siblings, 1 reply; 15+ messages in thread
From: Joseph Turner @ 2023-12-29 4:12 UTC (permalink / raw)
To: emacs-orgmode; +Cc: Adam Porter
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
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: Should org-link-parser add type "file" when link has no "file:" prefix? 2023-12-29 4:12 Should org-link-parser add type "file" when link has no "file:" prefix? Joseph Turner @ 2023-12-29 14:49 ` Ihor Radchenko 2023-12-29 22:05 ` Joseph Turner 0 siblings, 1 reply; 15+ messages in thread From: Ihor Radchenko @ 2023-12-29 14:49 UTC (permalink / raw) To: Joseph Turner; +Cc: emacs-orgmode, Adam Porter 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> ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Should org-link-parser add type "file" when link has no "file:" prefix? 2023-12-29 14:49 ` Ihor Radchenko @ 2023-12-29 22:05 ` Joseph Turner 2023-12-30 21:12 ` Joseph Turner 2023-12-31 15:07 ` Ihor Radchenko 0 siblings, 2 replies; 15+ messages in thread From: Joseph Turner @ 2023-12-29 22:05 UTC (permalink / raw) To: Ihor Radchenko; +Cc: emacs-orgmode, Adam Porter [-- 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) ^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: Should org-link-parser add type "file" when link has no "file:" prefix? 2023-12-29 22:05 ` Joseph Turner @ 2023-12-30 21:12 ` Joseph Turner 2023-12-31 15:07 ` Ihor Radchenko 1 sibling, 0 replies; 15+ messages in thread From: Joseph Turner @ 2023-12-30 21:12 UTC (permalink / raw) To: Ihor Radchenko, emacs-orgmode, Adam Porter [-- 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) ^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: Should org-link-parser add type "file" when link has no "file:" prefix? 2023-12-29 22:05 ` Joseph Turner 2023-12-30 21:12 ` Joseph Turner @ 2023-12-31 15:07 ` Ihor Radchenko 2024-01-01 6:52 ` Joseph Turner 1 sibling, 1 reply; 15+ messages in thread From: Ihor Radchenko @ 2023-12-31 15:07 UTC (permalink / raw) To: Joseph Turner; +Cc: emacs-orgmode, Adam Porter 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> ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Should org-link-parser add type "file" when link has no "file:" prefix? 2023-12-31 15:07 ` Ihor Radchenko @ 2024-01-01 6:52 ` Joseph Turner 2024-01-02 13:20 ` Ihor Radchenko 0 siblings, 1 reply; 15+ messages in thread From: Joseph Turner @ 2024-01-01 6:52 UTC (permalink / raw) To: Ihor Radchenko; +Cc: emacs-orgmode, Adam Porter 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Should org-link-parser add type "file" when link has no "file:" prefix? 2024-01-01 6:52 ` Joseph Turner @ 2024-01-02 13:20 ` Ihor Radchenko 2024-01-14 7:10 ` Joseph Turner 0 siblings, 1 reply; 15+ messages in thread From: Ihor Radchenko @ 2024-01-02 13:20 UTC (permalink / raw) To: Joseph Turner; +Cc: emacs-orgmode, Adam Porter 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> ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Should org-link-parser add type "file" when link has no "file:" prefix? 2024-01-02 13:20 ` Ihor Radchenko @ 2024-01-14 7:10 ` Joseph Turner 2024-01-16 13:40 ` Ihor Radchenko 0 siblings, 1 reply; 15+ messages in thread From: Joseph Turner @ 2024-01-14 7:10 UTC (permalink / raw) To: Ihor Radchenko; +Cc: emacs-orgmode, Adam Porter [-- 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 ^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: Should org-link-parser add type "file" when link has no "file:" prefix? 2024-01-14 7:10 ` Joseph Turner @ 2024-01-16 13:40 ` Ihor Radchenko 2024-01-16 20:16 ` Joseph Turner 0 siblings, 1 reply; 15+ messages in thread From: Ihor Radchenko @ 2024-01-16 13:40 UTC (permalink / raw) To: Joseph Turner; +Cc: emacs-orgmode, Adam Porter 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> ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Should org-link-parser add type "file" when link has no "file:" prefix? 2024-01-16 13:40 ` Ihor Radchenko @ 2024-01-16 20:16 ` Joseph Turner 2024-01-17 13:15 ` Ihor Radchenko 0 siblings, 1 reply; 15+ messages in thread From: Joseph Turner @ 2024-01-16 20:16 UTC (permalink / raw) To: Ihor Radchenko; +Cc: emacs-orgmode, Adam Porter 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 ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Should org-link-parser add type "file" when link has no "file:" prefix? 2024-01-16 20:16 ` Joseph Turner @ 2024-01-17 13:15 ` Ihor Radchenko 2024-01-31 22:10 ` joseph 0 siblings, 1 reply; 15+ messages in thread From: Ihor Radchenko @ 2024-01-17 13:15 UTC (permalink / raw) To: Joseph Turner; +Cc: emacs-orgmode, Adam Porter 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> ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Should org-link-parser add type "file" when link has no "file:" prefix? 2024-01-17 13:15 ` Ihor Radchenko @ 2024-01-31 22:10 ` joseph 2024-02-01 12:23 ` Ihor Radchenko 0 siblings, 1 reply; 15+ messages in thread From: joseph @ 2024-01-31 22:10 UTC (permalink / raw) To: Ihor Radchenko; +Cc: emacs-orgmode, Adam Porter 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 > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Should org-link-parser add type "file" when link has no "file:" prefix? 2024-01-31 22:10 ` joseph @ 2024-02-01 12:23 ` Ihor Radchenko 2024-02-02 4:35 ` joseph 0 siblings, 1 reply; 15+ messages in thread From: Ihor Radchenko @ 2024-02-01 12:23 UTC (permalink / raw) To: joseph; +Cc: emacs-orgmode, Adam Porter 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> ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Should org-link-parser add type "file" when link has no "file:" prefix? 2024-02-01 12:23 ` Ihor Radchenko @ 2024-02-02 4:35 ` joseph 2024-02-02 16:01 ` Ihor Radchenko 0 siblings, 1 reply; 15+ messages in thread From: joseph @ 2024-02-02 4:35 UTC (permalink / raw) To: Ihor Radchenko; +Cc: emacs-orgmode, Adam Porter 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 > ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Should org-link-parser add type "file" when link has no "file:" prefix? 2024-02-02 4:35 ` joseph @ 2024-02-02 16:01 ` Ihor Radchenko 0 siblings, 0 replies; 15+ messages in thread From: Ihor Radchenko @ 2024-02-02 16:01 UTC (permalink / raw) To: joseph; +Cc: emacs-orgmode, Adam Porter 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> ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2024-02-02 15:58 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-12-29 4:12 Should org-link-parser add type "file" when link has no "file:" prefix? Joseph Turner 2023-12-29 14:49 ` Ihor Radchenko 2023-12-29 22:05 ` Joseph Turner 2023-12-30 21:12 ` Joseph Turner 2023-12-31 15:07 ` Ihor Radchenko 2024-01-01 6:52 ` Joseph Turner 2024-01-02 13:20 ` Ihor Radchenko 2024-01-14 7:10 ` Joseph Turner 2024-01-16 13:40 ` Ihor Radchenko 2024-01-16 20:16 ` Joseph Turner 2024-01-17 13:15 ` Ihor Radchenko 2024-01-31 22:10 ` joseph 2024-02-01 12:23 ` Ihor Radchenko 2024-02-02 4:35 ` joseph 2024-02-02 16:01 ` Ihor Radchenko
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).