From: Joseph Turner <joseph@ushin.org>
To: Ihor Radchenko <yantar92@posteo.net>
Cc: emacs-orgmode@gnu.org, Adam Porter <adam@alphapapa.net>
Subject: Re: Should org-link-parser add type "file" when link has no "file:" prefix?
Date: Sun, 31 Dec 2023 22:52:04 -0800 [thread overview]
Message-ID: <87wmss1r51.fsf@ushin.org> (raw)
In-Reply-To: <87le9a76mk.fsf@localhost>
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
next prev parent reply other threads:[~2024-01-02 1:06 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87wmss1r51.fsf@ushin.org \
--to=joseph@ushin.org \
--cc=adam@alphapapa.net \
--cc=emacs-orgmode@gnu.org \
--cc=yantar92@posteo.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).