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

[Ihor Radchenko <yantar92@posteo.net>]

Max Nikulin <manikulin@gmail.com> 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 see no problem with special return value of the link :export function.
In fact, I thought of similar approach globally, allowing :export
function to return AST data that will be further processed.

WRT cons vs. plist, I am mostly neutral. Slightly in favour of plist for
future extensibility.

I am not sure what you mean by 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.

May you provide an example when the angle brackets are not added?

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

It is already the case. `org-export-data' maintains export cache under
:exported-data hash table in INFO plist. So, the second call to
`org-export-data` will be cached.

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

I see no reason to change the existing behaviour here. Yes, I do not see
much harm, but changing the defaults is something we should only do when
there is a clear benefit. Harm may not always be anticipated by us in
advance.

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

Do you mean "this is out of scope"?

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

May you show an example?

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

I do not think that we need to handle zero-width spaces on backend
level. If we want to deal with them, it should be done globally, in
ox.el.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>