On 07/10/2025 05:05, Steven Allen wrote:
I've attached two patches to implement this change. The first adds a
convenience org-export-link-with-backend function and implements the
change for man, docview, and doi (where the behavior change is fairly
minimal). The second extends this change to cover info links as well.

I like the idea to delegate export to a backend-specific function.

Please, be skeptical in respect to the following comments. I may be wrong.

Shouldn't org-manual.org "man:" link example for custom link types be updated as well?

+++ 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. For man links without description in plain text the convention is e.g. man(1), but it is more subtle since section sometimes is not known. From my point of view, http URL may make text harder to read.

+++ b/lisp/ol-doi.el

+(require 'ox)

I would consider (declare-function ...) to avoid eager loading of ox.

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

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.

+++ b/lisp/ol-info.el

+    (if (eq backend 'texinfo)

`org-export-derived-backend-p' should be better.

Reply via email to