Re: [RFC][PATCH v2] Allow to export to ascii custom link types as notes

[Max Nikulin]

On 07/11/2023 18:58, Ihor Radchenko wrote:
> Max Nikulin writes:
>
> > > (funcall protocol path desc backend info *link-object*)
> >
> > It would require another iteration with `condition-case' to deal with
> > functions having old signature.
>
> Is it a problem?

Performance for large projects like Worg.

> We can alternatively check function arity.

5 unnamed arguments for functions that are supposed to be implemented by 
users looks rather close to a border when it becomes fragile. The 
language does not enforce type checking for user-supplied functions and 
users would not bother as well. Multi-argument functions was a painful 
experience with FORTRAN for me (fortunately I was not deeply involved).

> > Earlier you considered :filter property that receives link object
> > instead of path and desc pair. I am unsure concerning name, but I like
> > that idea.
>
> I feel that :filter + :export will be rather redundant - they will do
> the same thing and only differ by calling convention. And we will have
> issues with priority of :filter vs. :export if both happen to be
> present (e.g. when a user defines a custom :export in personal config).

Fair point. :export should have precedence to not break user 
customization. Those who define :filter should set :export to nil. It is 
not perfect, but the extra argument is worse from my point of view.

> > > Then, if the :export function returns non-string, the return value is
> > > further processed as (org-export-data *return-value* info).
> >
> > Do you mean something like the following?
> >
> > (defun org-man-export (link description backend)
> >     "Export a man page LINK with DESCRIPTION.
> > BACKEND is the current export backend."
> >     (org-element-create-link
> >      (format "http://man.he.net/?topic=%s&section=all"; link)
> >      description))
>
> Yes.

It is nice idea for most backends, but it is unclear for me what the 
following function should return for ox-ascii

Ihor Radchenko. Re: Exporting elisp: and shell: links. Sun, 08 Oct 2023 
09:48:07 +0000.
https://list.orgmode.org/87r0m5phrc.fsf@localhost
> +(defun org-link--export-code (path description _ info &optional lang)
> +  "Export executable link with PATH and DESCRIPTION.
> +INFO is the current export info plist.
> +LANG is the language name, as in #+begin_src lang.  For example, \"elisp\"
> +or \"shell\"."
> +  (concat
> +   (org-export-data
> +    (org-element-create
> +     'inline-src-block
> +     `( :language ,lang
> +        :value ,path
> +        :parameters ":exports code :noweb no :eval never"))
> +    info)
> +   (when description (format " (%s)" description))))

Source code should be exported inline or as a note depending on 
preferences. This case exported element is not a link, so description 
should be treated separately.