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

[Max Nikulin <manikulin@gmail.com>]

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.