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

[Max Nikulin <manikulin@gmail.com>]

On 22/10/2023 16:13, Ihor Radchenko wrote:
> Max Nikulin writes:
> 
>> For ascii backend :export function from `org-link-parameters' may return
>> (PATH . DESCRIPTION) `cons' instead of string.
> 
> This is non-standard. We should document it somewhere in the manual.

Currently the question is whether it is acceptable or it should be 
changed to e.g. plist or even to use a callback.

>> I believe that parenthesis should be skipped in the case of angle
>> brackets "(<URI>)", but I do not change this behavior. There is some
>> inconsistency in respect to brackets for description of inline links,
>> but it is preserved as well.
> 
> May you elaborate?

I believe, parenthesis are not necessary when angle brackets are added 
around URI. Anyway currently behavior is not consistent and angle 
brackets are not added in some cases. I would prefer to stick to angle 
brackets and to drop parenthesis when <> are present.

>> I do not like that :export functions are called twice: for text and for
>> note. In my opinion it is better to collect links in a property of INFO
>> to later format notes at the end of the heading. I would consider more
>> dense style of notes with list markers instead of empty line as separator.
> 
> Again, may you elaborate?

List of links is added by `org-ascii--describe-links' that iterates over 
links earlier handled by `org-ascii-link', so :export function is called 
twice for each link having this property. I would consider collecting 
links in some property of the INFO argument instead. As a result 
`org-ascii--describe-link' would reuse results of formatters called by 
`org-ascii-link'.

Currently list of links is formatted as

[Description 1] <URL 1>

[Description 2] <URL 2>

 From my point of view it would not harm to have more dense formatting

- [Description 1] <URL 1>
- [Description 2] <URL 2>

>> +           (if (string-match-p "\\`\u200b*\\[.*\\]\u200b*\\'" anchor)
>> +               anchor
>> +	     (format "[%s]" anchor))
> 
> This is out of scope of the patch, isn't it?

Not really.

> I can see the motivation, but we should probably move this change to a
> separate patch and discussion thread.

In the case of inline links brackets are sometimes added around 
description, sometimes not. To keep current behavior I have decided that 
it is better to suppress duplicated brackets implicitly than to add an 
extra argument that controls adding [] explicitly. I do not insist on 
"\u200b*" that allows to handle duplication due to brackets in Org 
documents [[https://orgmode.org][\u200b[Org]\u200b]]. However I would 
prefer to keep the regexp for the case of brackets added by link formatters.