Hi,
At first, a couple of links to earlier discussions of link export
delegation when export function transforms it to a standard type.
Earlier messages in that threads may give more context
- Ihor Radchenko. Re: [RFC][PATCH v2] Allow to export to ascii custom
link types as notes. Tue, 07 Nov 2023 09:30:25 +0000.
<https://list.orgmode.org/87v8ad29n2.fsf@localhost>
- Ihor Radchenko. Re: [BUG] URI handling is overly complicated and
nonstandard. Sun, 03 Sep 2023 07:53:15 +0000.
<https://list.orgmode.org/878r9nofpw.fsf@localhost>
(:filter vs. :export)
On 08/10/2025 01:34, Steven Allen wrote:
Max Nikulin writes:
Shouldn't org-manual.org "man:" link example for custom link types be
updated as well?
Done.
Thanks
+++ b/etc/ORG-NEWS
+*** =man=, =docview=, and =doi= links are exported as HTTP links by default
+=man:foo=, etc.) with all other (non-hard-coded) backends. Now, such
+links are always transformed into =http= links before exporting,
+regardless of the backend. Importantly, this means that =docview= and
I do not think that doi links should be converted to http ones in the
case of the ascii backend.
[...]> I generally agree but here I'm just preserving existing behavior.
You are right. Unfortunately I can not suggest how to rewrite this
section to prominently say that behavior changed only if support of
specific backend was missed. Currently it sounds like that e.g. "man:"
links were not exported as HTTP links.
Info links export to ascii is changed, but it may be improved later.
+++ b/lisp/ox.el
+ (car (org-element-parse-secondary-string
+ (org-link-make-string link desc) '(link)))
I am surprised that format-and-parse approach is necessary. Generally, I
expect direct constructing of an element.
It was just the most easiest way to implement this with the fewest edge
cases to worry about. E.g., this way will correctly handle coderef,
custom-id, etc.
But I'm happy to change it to use org-element-create instead.
What I like in `org-link-make-string' is that it handles "]]" in link
description. On the other hand, I expect that org-element should have
helpers to create links.
I am afraid of obscure errors due to mistakes in custom user code
causing infinite loop. On the other hand some code to detect recursive
call with earlier seen type may have some performance impact.
[...]
Or because
org-export-link-with-backend recursively calls back into the export
backend?
[...]
The latter is a concern but I don't think it's worth
it to try to handle that case specifically (we'll error out either way).
I have not tried it in action. I just suspect that users may be confused
getting a stack overflow error without hints what part of the document
caused the failure.
+++ b/lisp/ol-docview.el
-(defun org-docview-export (link description backend _info)
- "Export a docview LINK with DESCRIPTION for BACKEND."
+(defun org-docview-export (link desc backend info)
+ "Export a docview LINK with DESC for BACKEND.
I like original variant "DESCRIPTION" more than truncated "DESC". It is
a matter of taste and may be ignored however.
+ (org-export-link-with-backend backend (expand-file-name path) desc
info))))
Perhaps I am not realizing exact effect, but I expect that adding
explicit "file:" scheme/type should be safer. Is it necessary to strip
search link path with the current approach?
(I am in doubts if relative path should be converted to absolute one,
but it is out of scope of your patch.)
+++ b/lisp/ol-info.el
+ (if (org-export-derived-backend-p backend 'texinfo)
+ (format "@ref{%s,%s,,%s,}" node (or desc "") manual)
I am realizing that `format' is here for ages, but I am surprised that
`org-texinfo-link' is not suitable here (Or is it? It should be in the
spirit of your patch.)
