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

[Max Nikulin <manikulin@gmail.com>]

On 23/10/2023 19:09, Ihor Radchenko wrote:
> Max Nikulin writes:
> 
> Then, `org-ascii-make-link-with-note' may as well receive and modify
> INFO plist. This way, ((org-export-custom-protocol-maybe link desc 'ascii info))
> cond form will work without changes as `org-ascii-make-link-with-note`
> will do all the necessary processing.

Adding INFO argument is a bit more burden for users, but, I think, it is 
acceptable.

However "cond form will work without changes" is not clear for me. 
`org-export-custom-protocol-maybe' is called twice and depending on 
context the result should be either "[description]" inline or 
"[description] path" for note, so the code around 
`org-export-custom-protocol-maybe' has to be changed.

>> angle and square brackets inconsistency
>>
>> --- 8< ---
>> # (require 'ol-man)
>> # (setq org-ascii-links-to-notes nil)
>>
>> - web :: [[http://orgmode.org][Org mode]]
>> - man :: [[man:man][man]]
>> - internal :: [[Heading][heading]]
>>
>> * Heading
>> --- >8 ---
>> --- 8< ---
>> web
>>         [Org mode] (<http://orgmode.org>)
>> man
>>         man (http://man.he.net/?topic=man&section=all)
> 
> This is probably a bug in ol-man.

Which one? Absence of square brackets? Absence of angle brackets? Both?

>> internal
>>         heading (See section 1)
> 
> I see no problem here - internal links are special, and it makes sense to
> drop angle brackets, unlike external web links that are often marked
> with angle brackets in the wild.

Due to absence of square brackets around "heading" it should be treated 
differently from e.g. http links. It is the reason why I added a regexp 
to detect if a caller added square brackets:

>>>>>> +           (if (string-match-p "\\`\u200b*\\[.*\\]\u200b*\\'" anchor)
>>>>>> +               anchor
>>>>>> +	     (format "[%s]" anchor))

I do not like repetitions in the current code.