From: Ihor Radchenko <[email protected]>
To: Bibek Panthi <[email protected]>
Cc: [email protected]
Subject: [RFC] Should we allow search options for all links types? (was: [PATCH] lisp/ox.el: Fix export of id links with search string)
Date: Sat, 17 May 2025 17:12:24 +0000 [thread overview]
Message-ID: <87tt5jkvpj.fsf@localhost> (raw)
In-Reply-To: <[email protected]>
Bibek Panthi <[email protected]> writes:
> In ox.el (org-export-resolve-id-link) we need to remove search string
> from path
> when checking for id.
>
> ID links can have search string. For example:
>
> id:4E8212FF-55F3-4E23-A63C-DB0EA8003FBA::*Heading
>
> This patch does the following:
>
> When searching for matching id, remove the part beginning at ::. For
> backwards compatibility with links that can have :: within their id,
> also check for any id that match the full path. This is similar to
> what is done at org-id-open in org-id.el .
Thanks for the patch!
The patch reveals a more general problem - introduction of search option
could have broken all the existing code (including third-party code)
that relies upon :path property of id: links.
Currently, search options are explicitly supported only for file: link
type. When one has file+emacs:/path/to/file.txt::extra, the link is split into
:type "file" :application "emacs" :path "/path/to/file.txt"
:search-option "extra"
In contrast, <id:20250517::* Heading> link is simply
:type "id" :path "20250517::* Heading". And we have to re-parse the
:path every time we need to work with the id: links.
What do you think about allowing *all* the link types to have a form of
<type>+<application>:<path>::<search option>? Then, the parser will
split all the typed links into :type, :application, :path = "<path>::<search-option>",
:path-no-search-option = "<path>", and :search-option.
Note that we cannot simply reuse :path because it can break links that
have :: as a part of actual path (say, http links). We should also leave
:path in file links as historical case to avoid breakage.
Maybe we can also take this opportunity to use # as an alternative to ::
and naturally support https://example.com/#anchor.
--
Ihor Radchenko // yantar92,
Org mode maintainer,
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>
next prev parent reply other threads:[~2025-05-17 17:14 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-14 5:22 [PATCH] lisp/ox.el: Fix export of id links with search string Bibek Panthi
2025-05-17 17:12 ` Ihor Radchenko [this message]
2025-05-18 4:35 ` [RFC] Should we allow search options for all links types? Bibek Panthi
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=87tt5jkvpj.fsf@localhost \
[email protected] \
[email protected] \
[email protected] \
/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.
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).