Re: [BUG] URI handling is overly complicated and nonstandard [9.6.7 (N/A @ /gnu/store/mg7223g8mw90lccp6mm5g6f3mpjk70si-emacs-org-9.6.7/share/emacs/site-lisp/org-9.6.7/)]

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> writes:

>>>     (org-link-set-parameters "tel")
> ...
>>>     \href{321}{call}
>>>
>>> "tel:" is missed.
>
> I have realized that it is possible to take advantage of current behavior:
>
>    (org-link-set-parameters
>     "browse"
>     :follow
>     (lambda (url arg) (browse-url url arg)))
>
> so [[browse:tel:+321][call]] with *any* protocol is properly exported 
> and opened. The only inconvenience is that the "browse:" type must be 
> added when a link is inserted or stripped down to copy a URL.

I strongly discourage abusing internal implementation details.
This behaviour is not documented. Moreover, I just suggested changing it.

>> (path (org-latex--protect-text
>>              (pcase type
>>                ((or "http" "https" "ftp" "mailto" "doi")
>>                 (concat type ":" raw-path))
>>                ("file"
>>                 (org-export-file-uri raw-path))
>>                (_
>>                 raw-path))))
>> 
>> is fishy.
>
> I do not like that lists of types in ox backends are not the same as in 
> ol.el:
>
> (dolist (scheme '("ftp" "http" "https" "mailto" "news"))
>    (org-link-set-parameters scheme

My suggestion will avoid the very need to have this list.

>> We may simply use (org-element-property :raw-link link) and leave
>> special handling to "file" links only.
>> 
>> Does it make sense?
>
>  From my point of view it will be more sane behavior. However it may 
> require update of 3rd party ox backends.

Yes. The main problem is that I fail to understand the motivation behind
the current behaviour. git logs reveal that the code is there from the
initial version of the library.

For now, the current behaviour looks like an oversight.
Also, only ox-latex-derived backends that worked around the current
undocumented behaviour might be affected.

>>> Actually I had in mind more flexible delegation. :export functions
>>> should be able to alter URI, attributes and to provide description if it
>>> is missed, but did not care if '<a href=""></a>' or '\href{}{}' should
>>> be used.
>> 
>> I'd call that :filter rather than :export :)
>
> It is an option, the only disadvantage is that `org-link-properties' can 
> not set an export filter directly.

What I meant is a new link property called :filter.

>>> Easy way to add protocol/scheme should include :follow with `browse-url'
>>> as well.
>> 
>> Sorry, but I do not understand what you are referring to.
>> May you elaborate?
>
> My reading of the bug report subject is that it should be easy to define 
> a link type for a protocol not supported by Org mode out of the box. 
> Minimal features are export and follow using a handler configured 
> desktop-wide or Emacs-wide.

This is not what the bug report was about. I'd prefer to focus this
particular discussion closer to the bug report reproducer.

Feel free to branch off a new feature request about :follow with more
details on what you have in mind. I'd prefer a more concrete proposal,
because I have no good ideas how to make things easier.

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