[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/)]

[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/)]

[Csepp]

I'm trying to include a tel: link in a curriculum vitae page that I want
to export to HTML.  Org-Mode fails during export because it thinks that
tel:+1234 is an internal link.  There seems to be no easy way to tell it
to just treat it the same way it would treat an HTTP link and include it
verbatim.  There does seem to be a way to do some Elisp scripting, but
it's honestly really annoying to do this for every protocol type.

Please, just let users include URLs in their docs.

Emacs  : GNU Emacs 28.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.37, cairo version 1.16.0)
Package: Org mode version 9.6.7 (N/A @ /gnu/store/mg7223g8mw90lccp6mm5g6f3mpjk70si-emacs-org-9.6.7/share/emacs/site-lisp/org-9.6.7/)

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/)]

[Max Nikulin]

On 31/08/2023 22:25, Csepp wrote:
> There seems to be no easy way to tell it
> to just treat it the same way it would treat an HTTP link and include it
> verbatim.  There does seem to be a way to do some Elisp scripting, but
> it's honestly really annoying to do this for every protocol type.
> 
> Please, just let users include URLs in their docs.

(info "(org) Adding Hyperlink Types")
https://orgmode.org/manual/Adding-Hyperlink-Types.html

(Side note: I would consider `org-export-derived-backend-p' instead of 
`pcase' with fixed symbols.)

So it is possible to have custom link types.

However I do not mind to have an easy way to delegate URI from :export 
function to the link transcoder of active export backend.

Current behavior with with treating link paths as fuzzy search targets 
is a kind of compromise. It allows internal search links to be shorter. 
One may have e.g. #+name: fig:something code blocks, so not every link 
looking as having some "scheme:" prefix should be treated as an external 
URI. As a result link types must be enabled explicitly.

[DISCUSSION] May we recognize everything like [[protocol:uri]] as a non-fuzzy link? (was: [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:

> However I do not mind to have an easy way to delegate URI from :export 
> function to the link transcoder of active export backend.

Just make the :export function return nil.

> Current behavior with with treating link paths as fuzzy search targets 
> is a kind of compromise. It allows internal search links to be shorter. 
> One may have e.g. #+name: fig:something code blocks, so not every link 
> looking as having some "scheme:" prefix should be treated as an external 
> URI. As a result link types must be enabled explicitly.

This is exactly the reason why Org recognizes a closed list of link
types and not just "anything looking like protocol:uri".

And I am honestly not a big fan - because of the limitations of Elisp
regexps, there is actually a hard limit on the number of link types we
can support - no more than few hundreds, AFAIR. This is because Elisp
regexps cannot be larger than certain length.

On the other hand, Org also supports "plain" links without brackets and
for such links it does make sense to avoid parsing something like A:B as
a link.

In theory, we might change the parser to treat anything like foo:bar or
<foo:bar> or [[foo:bar]] as a link with "foo" protocol and "bar" URI.
And introduce [[::fig:something]] to allow explicit internal links.
But, despite simplifying the parser, it will certainly be a breaking
change.

Any thoughts?

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

Re: [DISCUSSION] May we recognize everything like [[protocol:uri]] as a non-fuzzy link? (was: [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/)])

[Dr. Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 677 bytes --]


Ihor Radchenko <yantar92@posteo.net> writes:

> In theory, we might change the parser to treat anything like foo:bar or
> <foo:bar> or [[foo:bar]] as a link with "foo" protocol and "bar" URI.
> And introduce [[::fig:something]] to allow explicit internal links.
> But, despite simplifying the parser, it will certainly be a breaking
> change.
>
> Any thoughts?

Thinking about the effort I’d have to fix all internal links in all
org-documents I have (dozens of large ones and hundreds of small ones) I
don’t like the idea of breaking internal link syntax.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

Re: [DISCUSSION] May we recognize everything like [[protocol:uri]] as a non-fuzzy link? (was: [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]

"Dr. Arne Babenhauserheide" <arne_bab@web.de> writes:

>> Any thoughts?
>
> Thinking about the effort I’d have to fix all internal links in all
> org-documents I have (dozens of large ones and hundreds of small ones) I
> don’t like the idea of breaking internal link syntax.

May you elaborate about what is going to be broken?

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

Re: [DISCUSSION] May we recognize everything like [[protocol:uri]] as a non-fuzzy link? (was: [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/)])

[Dr. Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 844 bytes --]


Ihor Radchenko <yantar92@posteo.net> writes:

> "Dr. Arne Babenhauserheide" <arne_bab@web.de> writes:
>
>>> Any thoughts?
>>
>> Thinking about the effort I’d have to fix all internal links in all
>> org-documents I have (dozens of large ones and hundreds of small ones) I
>> don’t like the idea of breaking internal link syntax.
>
> May you elaborate about what is going to be broken?

I have many links where I use <<sec:spielbeispiel>> along with
[[sec:spielbeispiel]], often along with
@@latex:\phantomsection\label{sec:spielbeispiel}@@ to enable reliable
inline linking inside org-mode and across different export formats.

If I understood the proposal right, all of these would break. Or did I
misundestand that?

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

Re: [DISCUSSION] May we recognize everything like [[protocol:uri]] as a non-fuzzy link? (was: [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]

"Dr. Arne Babenhauserheide" <arne_bab@web.de> writes:

>> May you elaborate about what is going to be broken?
>
> I have many links where I use <<sec:spielbeispiel>> along with
> [[sec:spielbeispiel]], often along with
> @@latex:\phantomsection\label{sec:spielbeispiel}@@ to enable reliable
> inline linking inside org-mode and across different export formats.
>
> If I understood the proposal right, all of these would break. Or did I
> misundestand that?

What I had in mind is that only parser will be changed.
Now, [[sec:spielbeispiel]] is

(link :type "fuzzy" :path "sec:spielbeispiel" ...)

With my proposal, it would become

(link :type "sec" :path "spielbeispiel" ...)

However, "sec" link type will still not be listed in the output
`org-link-types' (not registered).

Then, ox.el and other link processing code, when encountering a link
type that is not registered, will fall back to searching "fuzzy" link.

So, export, and following the link should not be affected.

There might be caveats related to parser though.

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

Re: [DISCUSSION] May we recognize everything like [[protocol:uri]] as a non-fuzzy link? (was: [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/)])

[Dr. Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 457 bytes --]


Ihor Radchenko <yantar92@posteo.net> writes:

> Then, ox.el and other link processing code, when encountering a link
> type that is not registered, will fall back to searching "fuzzy" link.
>
> So, export, and following the link should not be affected.

This resolves my worry — thank you!

> There might be caveats related to parser though.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

Re: [DISCUSSION] May we recognize everything like [[protocol:uri]] as a non-fuzzy link? (was: [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/)])

[Max Nikulin]

On 02/09/2023 14:26, Ihor Radchenko wrote:
> With my proposal, it would become
> 
> (link :type "sec" :path "spielbeispiel" ...)
> 
> However, "sec" link type will still not be listed in the output
> `org-link-types' (not registered).
> 
> Then, ox.el and other link processing code, when encountering a link
> type that is not registered, will fall back to searching "fuzzy" link.
> 
> So, export, and following the link should not be affected.

I do not see which way it may help in the reported case of complications 
with URI schemes not enabled by default. What is the purpose of parser 
changes if links can not be exported or opened?

I am unsure if any "PREFIX:" should be recognized as a link type, but 
there is another possibility on this way: allow users to mark some 
prefixes as search links, not link types.

Taking into account requests to enable more URI schemes by default, 
requiring to explicitly disable some prefixes may be acceptable 
compromise. It may be necessary even if fixed set of link types is 
allowed by default instead of arbitrary prefix.

Changes of behavior disturbs a part of users, but strictly adhering 
backward compatibility means inconvenience for others.

Re: [DISCUSSION] May we recognize everything like [[protocol:uri]] as a non-fuzzy link? (was: [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:

> On 02/09/2023 14:26, Ihor Radchenko wrote:
>> With my proposal, it would become
>> 
>> (link :type "sec" :path "spielbeispiel" ...)
>> 
>> However, "sec" link type will still not be listed in the output
>> `org-link-types' (not registered).
>> 
>> Then, ox.el and other link processing code, when encountering a link
>> type that is not registered, will fall back to searching "fuzzy" link.
>> 
>> So, export, and following the link should not be affected.
>
> I do not see which way it may help in the reported case of complications 
> with URI schemes not enabled by default. What is the purpose of parser 
> changes if links can not be exported or opened?

What I had in mind is a bit elaborate:
1. We get actual link type
2. If link type is not registered, we try "fuzzy"
3. If "fuzzy" target is not found, instead of broken link, we export a
   link with unknown type.

> I am unsure if any "PREFIX:" should be recognized as a link type, but 
> there is another possibility on this way: allow users to mark some 
> prefixes as search links, not link types.

May you elaborate?

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

Re: [DISCUSSION] May we recognize everything like [[protocol:uri]] as a non-fuzzy link? (was: [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/)])

[Max Nikulin]

On 05/09/2023 18:02, Ihor Radchenko wrote:
> 
> What I had in mind is a bit elaborate:
> 1. We get actual link type
> 2. If link type is not registered, we try "fuzzy"
> 3. If "fuzzy" target is not found, instead of broken link, we export a
>     link with unknown type.

It makes sense as an additional variant for 
`org-export-with-broken-links'. Currently no option allows to export 
description of broken links and sometimes it is inconvenient.

> Max Nikulin writes:
>> I am unsure if any "PREFIX:" should be recognized as a link type, but
>> there is another possibility on this way: allow users to mark some
>> prefixes as search links, not link types.
> 
> May you elaborate?

I am considering another behavior. If any PREFIX: is recognized then the 
link exported literally as PREFIX:PATH unless the PREFIX is registered as

    (org-link-register-search-link-prefix "sec")

So if the document does not contain PREFIX:NAME target then it is an 
export error (or another prescription controlled by 
`org-export-with-broken-links') and it may be reported so by `org-lint'.

Different users expect different degree of strictness during link 
export. I am unsure which variant is better.

Re: [DISCUSSION] May we recognize everything like [[protocol:uri]] as a non-fuzzy link? (was: [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:

>> Max Nikulin writes:
>>> I am unsure if any "PREFIX:" should be recognized as a link type, but
>>> there is another possibility on this way: allow users to mark some
>>> prefixes as search links, not link types.
>> 
>> May you elaborate?
>
> I am considering another behavior. If any PREFIX: is recognized then the 
> link exported literally as PREFIX:PATH unless the PREFIX is registered as
>
>     (org-link-register-search-link-prefix "sec")
>
> So if the document does not contain PREFIX:NAME target then it is an 
> export error (or another prescription controlled by 
> `org-export-with-broken-links') and it may be reported so by `org-lint'.
>
> Different users expect different degree of strictness during link 
> export. I am unsure which variant is better.

I feel that it will be too complex.
We might simply throw a warning when we get unregistered [[type:path]]
link, so that the user can notice if there is any problem.

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

Re: [DISCUSSION] May we recognize everything like [[protocol:uri]] as a non-fuzzy link? (was: [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/)])

[Max Nikulin]

On 07/09/2023 17:42, Ihor Radchenko wrote:
> Max Nikulin writes:
>>
>> I am considering another behavior. If any PREFIX: is recognized then the
>> link exported literally as PREFIX:PATH unless the PREFIX is registered as
>>
>>      (org-link-register-search-link-prefix "sec")
>>
>> So if the document does not contain PREFIX:NAME target then it is an
>> export error (or another prescription controlled by
>> `org-export-with-broken-links') and it may be reported so by `org-lint'.
>>
>> Different users expect different degree of strictness during link
>> export. I am unsure which variant is better.
> 
> I feel that it will be too complex.
> We might simply throw a warning when we get unregistered [[type:path]]
> link, so that the user can notice if there is any problem.

I do not think it noticeably increases complexity in comparison to the 
current state of affairs, but I agree concerning warnings. It would be 
great.

It is my dream for a long time to get a buffer with export warnings in 
`compilation-mode' with file:lineno labels. I admit it may be a 
challenge taking into account include directives and various filters 
that changes content of export buffer.

Re: [DISCUSSION] May we recognize everything like [[protocol:uri]] as a non-fuzzy link? (was: [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:

>> 
>> I feel that it will be too complex.
>> We might simply throw a warning when we get unregistered [[type:path]]
>> link, so that the user can notice if there is any problem.
>
> I do not think it noticeably increases complexity in comparison to the 
> current state of affairs, but I agree concerning warnings. It would be 
> great.

Yeah. But, as usual, someone™ has to do it.
Another common request is synctex support for Org source buffers.

> It is my dream for a long time to get a buffer with export warnings in 
> `compilation-mode' with file:lineno labels. I admit it may be a 
> challenge taking into account include directives and various filters 
> that changes content of export buffer.

Not necessarily. At least, includes are trivial - the buffer ox.el works
on is not the original buffer, but a copy with all the includes
expanded, everything that should be removed - removed, and everything
that should be edited - edited. So, we may simply link to that buffer.

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

Re: [DISCUSSION] May we recognize everything like [[protocol:uri]] as a non-fuzzy link?

[Jens Lechtenboerger]

On 2023-09-01, Ihor Radchenko wrote:

> In theory, we might change the parser to treat anything like foo:bar or
> <foo:bar> or [[foo:bar]] as a link with "foo" protocol and "bar" URI.
> And introduce [[::fig:something]] to allow explicit internal links.
> But, despite simplifying the parser, it will certainly be a breaking
> change.

What would the implications be?  FAQ 18.25 [1] contains a recipe to
use colors on text like this: [[color:red][red]]

Would that be a problem?

Also, I use custom link types for additional markup like this:

[[basic:https://en.wikipedia.org/wiki/Cache_(computing)][Caching]]

In both cases, the part before the first colon is certainly no
protocol.

Besides, concerning wording in this discussion: A URIs may or may
not embed a protocol.  It contains a scheme, then a colon, then a
scheme-specific part, see [2].

Best wishes
Jens

[1] https://orgmode.org/worg/org-faq.html
[2] https://datatracker.ietf.org/doc/html/rfc3986

Re: [DISCUSSION] May we recognize everything like [[protocol:uri]] as a non-fuzzy link?

[Ihor Radchenko]

Jens Lechtenboerger <lechten@wi.uni-muenster.de> writes:

> On 2023-09-01, Ihor Radchenko wrote:
>
>> In theory, we might change the parser to treat anything like foo:bar or
>> <foo:bar> or [[foo:bar]] as a link with "foo" protocol and "bar" URI.
>> And introduce [[::fig:something]] to allow explicit internal links.
>> But, despite simplifying the parser, it will certainly be a breaking
>> change.
>
> What would the implications be?  FAQ 18.25 [1] contains a recipe to
> use colors on text like this: [[color:red][red]]
>
> Would that be a problem?
>
> Also, I use custom link types for additional markup like this:
>
> [[basic:https://en.wikipedia.org/wiki/Cache_(computing)][Caching]]
>
> In both cases, the part before the first colon is certainly no
> protocol.

Sorry for the confusion. I mean link type in Org parser terms, not
protocol.

Your examples will not be affected. What will be affected is fuzzy
internal links.

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

Re: [DISCUSSION] May we recognize everything like [[protocol:uri]] as a non-fuzzy link? (was: [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/)])

[Tom Gillespie]

This is a timely discussion. I have been thinking about how
to deal with prefixes defined by the #+link: keyword which is
directly related to this question.

I think the following might be a solution that also avoids the
issue brought up by Arne.

The original "bug" cannot be resolved because bare URIs
have syntax that conflicts with Org syntax. However I think
we can do better than directing users to org-link-set-parameters.

My suggestion is as follows. Schemes/prefixes defined by the
#+link: keyword can be used without surrounding syntax markers
but may not contain spaces etc. To support this Org parsers
should always parse prefix:suffix as a _putative_ link which
must then be checked against a list of known schemes that
are either built in or have been declared by the user to indeed
be legitimate schemes.

In the tel: case, the way to solve the original bug is simply
to add the line #+link: tel tel: which would tell Org that e.g.
tel:555-555-5555 is a real uri, and that it should expand to
itself.

At the same time this solution would avoid Arne's issue
(which I also have in some of my documents where I have
use fig: and tbl: as prefixes in names and reference them
via [[fig:figure-name]]) because the parser would only treat
prefix: in an internal link as a scheme if it is defined explicitly
by the user in a #+link: keyword or in their init.el.

Thoughts?
Tom

Re: [DISCUSSION] May we recognize everything like [[protocol:uri]] as a non-fuzzy link? (was: [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]

Tom Gillespie <tgbugs@gmail.com> writes:

> My suggestion is as follows. Schemes/prefixes defined by the
> #+link: keyword can be used without surrounding syntax markers
> but may not contain spaces etc.

> ... To support this Org parsers
> should always parse prefix:suffix as a _putative_ link which
> must then be checked against a list of known schemes that
> are either built in or have been declared by the user to indeed
> be legitimate schemes.
>
> In the tel: case, the way to solve the original bug is simply
> to add the line #+link: tel tel: which would tell Org that e.g.
> tel:555-555-5555 is a real uri, and that it should expand to
> itself.

Currently, link abbreviations are explicitly allowed in bracket links
and only bracket links.

The currently available  way to force tel: link type is using angle
links:

<tel:555-555-5555>

No special #+link keyword is needed in the above example.

> At the same time this solution would avoid Arne's issue
> (which I also have in some of my documents where I have
> use fig: and tbl: as prefixes in names and reference them
> via [[fig:figure-name]]) because the parser would only treat
> prefix: in an internal link as a scheme if it is defined explicitly
> by the user in a #+link: keyword or in their init.el.

The most annoying part is that we have three not fully consistent link
markups:

http://plain-link.com
<http://angle-link.com>
[[http://bracket-link.com]]

The plain link only works for `org-link-types' - registered link types.

The angle link works all the time, unconditionally parsing <foo:bar>
with "foo" being link type and "bar" being link path. Abbreviations are ignored.

The bracket link works only for `org-link-types' __and__ link
abbreviations. If whatever inside brackets is not matching know link
type or abbreviation, it is considered a fuzzy link.


As you see, the situation might easily get confusing in corner cases.

My proposal aims to extend the bracket link a bit - the most commonly
used link type. However, it creates a problem with fuzzy links.
Even more problematic is plain link type where any kind of open syntax
will likely clash with normal text flow with innocent text like A:B
being suddenly considered a link.

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

[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/)]

[Max Nikulin]

On 01/09/2023 16:04, Ihor Radchenko wrote:
> Max Nikulin writes:
> 
>> However I do not mind to have an easy way to delegate URI from :export
>> function to the link transcoder of active export backend.

> Just make the :export function return nil.

I missed this feature, but anyway it does not work as expected.

   (org-link-set-parameters "tel")

or

   (org-link-set-parameters
    "tel"
    :export (lambda (_path _descr _backend) nil))

strips link type and exports links as e.g.

   \href{321}{call}

"tel:" is missed. Each backend has its own hardcoded list of blessed 
link types to preserve link type/protocol/scheme:
- LaTeX: "http" "https" "ftp" "mailto" "doi"
- HTML:  "http" "https" "ftp" "mailto" "news"

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.

Easy way to add protocol/scheme should include :follow with `browse-url' 
as well.

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:

> On 01/09/2023 16:04, Ihor Radchenko wrote:
>> Max Nikulin writes:
>> 
>>> However I do not mind to have an easy way to delegate URI from :export
>>> function to the link transcoder of active export backend.
>
>> Just make the :export function return nil.
>
> I missed this feature, but anyway it does not work as expected.
>
>    (org-link-set-parameters "tel")
>
> or
>
>    (org-link-set-parameters
>     "tel"
>     :export (lambda (_path _descr _backend) nil))
>
> strips link type and exports links as e.g.
>
>    \href{321}{call}
>
> "tel:" is missed. Each backend has its own hardcoded list of blessed 
> link types to preserve link type/protocol/scheme:
> - LaTeX: "http" "https" "ftp" "mailto" "doi"
> - HTML:  "http" "https" "ftp" "mailto" "news"

In `org-latex-link',

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

We may simply use (org-element-property :raw-link link) and leave
special handling to "file" links only.

Does it make sense?

> 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 :)
Have nothing against it, though it is not 100% relevant to this
particular report.

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

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

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/)]

[Max Nikulin]

On 03/09/2023 14:53, Ihor Radchenko wrote:
> Max Nikulin writes:
>> I missed this feature, but anyway it does not work as expected.
>>
>>     (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.

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

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

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

> Have nothing against it, though it is not 100% relevant to this
> particular report.

If there were an `org-link-properties' field to export link as a parsed 
element, not just path and description then it would be easier to define 
backend agnostic export function for a non-standard link type.

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

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>

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/)]

[Max Nikulin]

On 05/09/2023 16:42, Ihor Radchenko wrote:
> Max Nikulin writes:
>>
>>   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.

Just a guess, likely unrelated to actual decision. For links like 
"lisp:" or "shell:" keeping link type does not have much sense (however 
stripping it is questionable as well).

 From my point of view, e.g. <elisp:(identity "a")> should be exported 
as plain text <code>(identity "a")</code> rather than an (invalid due to 
not escaped quotes inside href) link <a href="(identity "a")">(identity 
"a")</a>.

I still believe that fallback export should preserve link type. Code 
links should define their export functions.

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/)]

[Rudolf Adamkovič]

Max Nikulin <manikulin@gmail.com> writes:

> From my point of view, e.g. <elisp:(identity "a")> should be exported 
> as plain text <code>(identity "a")</code> rather than an (invalid due to 
> not escaped quotes inside href) link <a href="(identity "a")">(identity 
> "a")</a>.

This would be a very welcome fix!  I avoid
'elisp' links, even in my Emacs notes, as
they do not export correctly.

Rudy
-- 
"Chop your own wood and it will warm you twice."
-- Henry Ford; Francis Kinloch, 1819; Henry David Thoreau, 1854

Rudolf Adamkovič <salutis@me.com> [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

Exporting elisp: and shell: links

[Max Nikulin]

On 18/09/2023 05:08, Rudolf Adamkovič wrote:
> Max Nikulin writes:
> 
>>  From my point of view, e.g. <elisp:(identity "a")> should be exported
>> as plain text <code>(identity "a")</code> rather than an (invalid due to
>> not escaped quotes inside href) link <a href="(identity "a")">(identity
>> "a")</a>.
> 
> This would be a very welcome fix!  I avoid
> 'elisp' links, even in my Emacs notes, as
> they do not export correctly.

Do you think a label specifying language should be added to code 
snippets, e.g. <code title="elisp">(identity "a")</code> or it is 
useless and may cause undesired noise for screen reader users? What 
about LaTeX?

What is your expectation for links having description?

   [[elisp:(identity "a")][Run it]]

Unsure if making plain text from description is the best solution. Some 
interactive element may be added to HTML to reveal the code or at least 
it may be put into tooltip <span class="code" title="elisp:(identity 
&quot;a&quot;)">Run it</span>. The downside is that title attribute can 
not be easily copied (at least without a dedicated extension). ODT and 
LaTeX are more tricky again (a footnote?).

Re: Exporting elisp: and shell: links

[Rudolf Adamkovič]

Max Nikulin <manikulin@gmail.com> writes:

> Do you think a label specifying language should be added to code 
> snippets, e.g. <code title="elisp">(identity "a")</code> or it is 
> useless and may cause undesired noise for screen reader users? What 
> about LaTeX?

As a user, I would expect

  [[elisp:(identity "a")]]

to be export-equivalent to

  src_elisp[:exports code]{(identity "a")}

across all backends.

[If Org works as it should, then that solves
screen readers, LaTeX, etc.]

> What is your expectation for links having description?
>
>    [[elisp:(identity "a")][Run it]]

Good point!  Perhaps we just need to find a
good symbol that would work well between the
Elisp code and the description?

For example

  /Run it/ \to src_elisp[:exports code]{(identity "a")}

exports to ASCII as

  /Run it/ -> `(identity "a")'

Of course, \to could be something else...

WDYT?

Rudy
-- 
"Thinking is a momentary dismissal of irrelevancies."
-- Richard Buckminster Fuller, 1969

Rudolf Adamkovič <salutis@me.com> [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

Re: Exporting elisp: and shell: links

[Max Nikulin]

On 19/09/2023 07:10, Rudolf Adamkovič wrote:
> Max Nikulin <manikulin@gmail.com> writes:
> 
>> Do you think a label specifying language should be added to code
>> snippets, e.g. <code title="elisp">(identity "a")</code> or it is
>> useless and may cause undesired noise for screen reader users? What
>> about LaTeX?
> 
> As a user, I would expect
> 
>    [[elisp:(identity "a")]]
> 
> to be export-equivalent to
> 
>    src_elisp[:exports code]{(identity "a")}
> 
> across all backends.

(defun org-link-export-eval-link-no-descr
     (type path descr backend info)
   (unless descr
     (let ((element
	   (org-element-create
	    'inline-src-block
	    (list :language type
		  :value path
		  :parameters ":exports code :noweb no :eval never"))))
       (org-export-data element info))))

(defun org-link-make-export-eval-link-no-descr (type)
   (lambda (path descr backend info)
	   (org-link-export-eval-link-no-descr
	    type path descr backend info)))

(dolist (type '("elisp" "shell"))
   (org-link-set-parameters
    type
    :export (org-link-make-export-eval-link-no-descr type)))

>> What is your expectation for links having description?
>>
>>     [[elisp:(identity "a")][Run it]]
> 
> Good point!  Perhaps we just need to find a
> good symbol that would work well between the
> Elisp code and the description?
> 
> For example
> 
>    /Run it/ \to src_elisp[:exports code]{(identity "a")}
> 
> exports to ASCII as
> 
>    /Run it/ -> `(identity "a")'
> 
> Of course, \to could be something else...

I have another example:

    [[elisp:(server-start)][=M-x server-start RET=]]

suitable for a printed document.

 From my point of view, it is better either to drop link path completely 
or to add a button to copy the code to clipboard. Repetition is undesired.

So I am unsure if it is possible to choose unambiguous rules for export 
of elisp and shell links.

Re: Exporting elisp: and shell: links

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> writes:

>> As a user, I would expect
>> 
>>    [[elisp:(identity "a")]]
>> 
>> to be export-equivalent to
>> 
>>    src_elisp[:exports code]{(identity "a")}
>> 
>> across all backends.

Makes sense.

>>> What is your expectation for links having description?
>>>
>>>     [[elisp:(identity "a")][Run it]]
>> 
>> Good point!  Perhaps we just need to find a
>> good symbol that would work well between the
>> Elisp code and the description?
>> 
>> For example
>> 
>>    /Run it/ \to src_elisp[:exports code]{(identity "a")}
>> 
>> exports to ASCII as
>> 
>>    /Run it/ -> `(identity "a")'
>> 
>> Of course, \to could be something else...

Another idea: use code as description displayed in the tooltip (in html).
Copy-on-clip also makes sense.

Yet another idea: export code inside a footnote. This will work across
all the backends.

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

Re: Exporting elisp: and shell: links

[Rudolf Adamkovič]

Ihor Radchenko <yantar92@posteo.net> writes:

> Another idea: use code as description displayed in the tooltip (in html).
> Copy-on-clip also makes sense.
>
> Yet another idea: export code inside a footnote. This will work across
> all the backends.

Yet another, another idea: export the description as a Lisp comment,
after converting it to plain text.  To use Max's example:

src_elisp[:exports code]{(server-start) ; Launch server}
src_elisp[:exports code]{(server-start) ; `M-x server-start RET'}

Rudy
-- 
"Logic is a science of the necessary laws of thought, without which no
employment of the understanding and the reason takes place."
-- Immanuel Kant, 1785

Rudolf Adamkovič <salutis@me.com> [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

Re: Exporting elisp: and shell: links

[Max Nikulin]

On 23/09/2023 06:43, Rudolf Adamkovič wrote:
> Ihor Radchenko writes:
> 
>> Another idea: use code as description displayed in the tooltip (in html).
>> Copy-on-clip also makes sense.
>>
>> Yet another idea: export code inside a footnote. This will work across
>> all the backends.
> 
> Yet another, another idea: export the description as a Lisp comment,
> after converting it to plain text.  To use Max's example:
> 
> src_elisp[:exports code]{(server-start) ; Launch server}
> src_elisp[:exports code]{(server-start) ; `M-x server-start RET'}

I do not think, code with comments is suitable for inline source blocks, 
such code should occupy a dedicated line.

I am afraid, there is no variant that fits for all cases even in a 
particular document. It would be great to mark specific links, which way 
each one should be exported:

     You should run
     <attr:(:omit-code t)>[[elisp:(server-start)][=M-x server-start=]].
     Or you can [[elisp:(identity "a")][run it]].

     <p>You should run
     <code data-org-link="(server-start)">M-x server-start</code>.
     Or you can <span class="eval-link">run it</span> ->
     <code>(identity "a")</code>.

I know, Ihor do not like the idea of attributes for inline objects
due to complexity of current implementation of parser for #+attr_html:

Ihor Radchenko. Re: [HELP] Fwd: Org format as a new standard source 
format for GNU manuals. Mon, 03 Oct 2022 12:36:20 +0800. 
https://list.orgmode.org/87r0zpy14r.fsf@localhost

Re: Exporting elisp: and shell: links

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> writes:

> I am afraid, there is no variant that fits for all cases even in a 
> particular document.

Still, it would be nice to have _a_ variant compared to the current
state of affairs.

As for extra customization, it totally depends on the interest in this
functionality. If not many people are interested, I'd put one variant in
Org and left non-standard export to the users to customize via :export
link property.

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

Re: Exporting elisp: and shell: links

[Rudolf Adamkovič]

Ihor Radchenko <yantar92@posteo.net> writes:

> Still, it would be nice to have _a_ variant compared to the current
> state of affairs.

Agreed.  If the link has no description, we can do a great job on
exporting it.  Half of the victory, right there!

Also, how about the following /simple/ idea for the description:

  [[elisp:(server-start)][Launch Server]]
  [[elisp:(server-start)][=M-x server-start RET=]]
  
  src_elisp[:exports code]{(server-start)} (Launch Server)
  src_elisp[:exports code]{(server-start)} (=M-x server-start RET=)

TL;DR We export the description, if any, in parentheses after the code.

Rudy
-- 
"One can begin to reason only when a clear picture has been formed in
the imagination."
-- Walter Warwick Sawyer, Mathematician's Delight, 1943

Rudolf Adamkovič <salutis@me.com> [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

Re: Exporting elisp: and shell: links

[Ihor Radchenko]

[-- Attachment #1: Type: text/plain, Size: 1360 bytes --]

Rudolf Adamkovič <salutis@me.com> writes:

>> Still, it would be nice to have _a_ variant compared to the current
>> state of affairs.
>
> Agreed.  If the link has no description, we can do a great job on
> exporting it.  Half of the victory, right there!
>
> Also, how about the following /simple/ idea for the description:
>
>   [[elisp:(server-start)][Launch Server]]
>   [[elisp:(server-start)][=M-x server-start RET=]]
>   
>   src_elisp[:exports code]{(server-start)} (Launch Server)
>   src_elisp[:exports code]{(server-start)} (=M-x server-start RET=)
>
> TL;DR We export the description, if any, in parentheses after the code.

See the attached diff, implementing your suggestion.
I am not sure if I like it.

Consider the following example file:

----
#+options: toc:nil author:nil

[[elisp:(message "Hello")]]

[[elisp:(message "Hello")][Message Hello]]
----

Without the diff, exporting to ASCII yields

----
<elisp:(message "Hello")>

[Message Hello]


[Message Hello] <elisp:(message "Hello")>
----

with the diff:

----
`(message "Hello")'

`(message "Hello")' (Message Hello)
---

For markdown:

without diff:
---
<(message "Hello")>

[Message Hello]((message "Hello"))

---

with:
---
`(message "Hello")`

`(message "Hello")` (Message Hello)
---

For html:

without diff:

[-- Attachment #2: html-without-diff.png --]
[-- Type: image/png, Size: 10838 bytes --]

[-- Attachment #3: Type: text/plain, Size: 7 bytes --]


with:

[-- Attachment #4: html-with-diff.png --]
[-- Type: image/png, Size: 13552 bytes --]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #5: code-link-export.diff --]
[-- Type: text/x-patch, Size: 1755 bytes --]

diff --git a/lisp/ol.el b/lisp/ol.el
index 20aab6bb8..d537709ac 100644
--- a/lisp/ol.el
+++ b/lisp/ol.el
@@ -1377,7 +1377,29 @@ (defun org-link--open-elisp (path _)
 		 (call-interactively (read path))))
     (user-error "Abort")))
 
-(org-link-set-parameters "elisp" :follow #'org-link--open-elisp)
+(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))))
+
+(defun org-link--export-elisp (path description _ info)
+  "Export elisp: link with PATH and DESCRIPTION according to INFO channel."
+  (org-link--export-code path description nil info "emacs-lisp"))
+
+(org-link-set-parameters
+ "elisp"
+ :follow #'org-link--open-elisp
+ :export #'org-link--export-elisp)
 
 ;;;; "file" link type
 (org-link-set-parameters "file" :complete #'org-link-complete-file)
@@ -1435,7 +1457,14 @@ (defun org-link--open-shell (path _)
 		      clean-buffer-list-kill-buffer-names))))
     (user-error "Abort")))
 
-(org-link-set-parameters "shell" :follow #'org-link--open-shell)
+(defun org-link--export-shell (path description _ info)
+  "Export shell: link with PATH and DESCRIPTION according to INFO channel."
+  (org-link--export-code path description nil info "shell"))
+
+(org-link-set-parameters
+ "shell"
+ :follow #'org-link--open-shell
+ :export #'org-link--export-shell)
 
 \f
 ;;; Interactive Functions

[-- Attachment #6: Type: text/plain, Size: 225 bytes --]



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

Re: Exporting elisp: and shell: links

[Max Nikulin]

On 08/10/2023 16:48, Ihor Radchenko wrote:
> +++ b/lisp/ol.el
> @@ -1377,7 +1377,29 @@ (defun org-link--open-elisp (path _)
>  		 (call-interactively (read path))))
>      (user-error "Abort")))
>  
> -(org-link-set-parameters "elisp" :follow #'org-link--open-elisp)
> +(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)

I think, the fragment above should be a public function that is a 
building block for users who want to override export of links having 
descriptions.

> +   (when description (format " (%s)" description))))

I hope, path was never added as default description, so checks (or 
(string-equal path description) (string-equal (concat type ":" path) 
description))) are not necessary to avoid annoying repetitions.

Re: Exporting elisp: and shell: links

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> writes:

>> +(defun org-link--export-code (path description _ info &optional lang)
>
> I think, the fragment above should be a public function that is a 
> building block for users who want to override export of links having 
> descriptions.

Sure, but that's minor.

>> +   (when description (format " (%s)" description))))
>
> I hope, path was never added as default description, so checks (or 
> (string-equal path description) (string-equal (concat type ":" path) 
> description))) are not necessary to avoid annoying repetitions.

Valid, but I am more concerned about the whole idea. I _feel_ that

    code (description)
    
does not look nice in html export. I like more how ox-ascii (without the
proposed diff) handles the situation via footnote-like link.

That's my personal preferences though. Which is why I want to hear more
opinions. In particular, I encourage others to play around with various
exported documents with and without the diff and comment on how they
look.

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

Re: Exporting elisp: and shell: links

[Max Nikulin]

On 09/10/2023 19:12, Ihor Radchenko wrote:
> Valid, but I am more concerned about the whole idea. I _feel_ that
> 
>     code (description)
>     
> does not look nice in html export.

It is minor in comparison with invalid HTML that may be generated by 
current code. I am unsure if a better variant exist, but to evaluate it 
several real life examples are required.

> I like more how ox-ascii (without the
> proposed diff) handles the situation via footnote-like link.

That is why I believe that extracting fragments of code into helper 
functions is important. If ox-ascii.el had a function that adds an item 
to link list then ol.el would use it to add src_elisp elements to this list.

Re: Exporting elisp: and shell: links

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> writes:

>> I like more how ox-ascii (without the
>> proposed diff) handles the situation via footnote-like link.
>
> That is why I believe that extracting fragments of code into helper 
> functions is important. If ox-ascii.el had a function that adds an item 
> to link list then ol.el would use it to add src_elisp elements to this list.

May you elaborate? I am not talking about implementation details, but
about the reasonable defaults for the export. Not necessary ASCII, but
other backends as well.

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

Re: Exporting elisp: and shell: links

[Max Nikulin]

On 12/10/2023 18:35, Ihor Radchenko wrote:
> Max Nikulin writes:
> 
>>> I like more how ox-ascii (without the
>>> proposed diff) handles the situation via footnote-like link.
>>
>> That is why I believe that extracting fragments of code into helper
>> functions is important. If ox-ascii.el had a function that adds an item
>> to link list then ol.el would use it to add src_elisp elements to this list.
> 
> May you elaborate? I am not talking about implementation details, but
> about the reasonable defaults for the export. Not necessary ASCII, but
> other backends as well.
I am rather skeptical concerning a variant that is pleasant to read in 
all cases. That is why I suggest to provide tools that allow to 
customize export accordingly their writing styles.

ASCII is a special case since it uses end note style to present link 
targets.

Whether code is added before link description or after it, either 
parenthesis are used or not, the following functions may be convenient 
for Org and for users:
- export argument as inline source block
- add an item to ASCII list of links

Re: Exporting elisp: and shell: links

[Ihor Radchenko]

Max Nikulin <manikulin@gmail.com> writes:

>> May you elaborate? I am not talking about implementation details, but
>> about the reasonable defaults for the export. Not necessary ASCII, but
>> other backends as well.
> I am rather skeptical concerning a variant that is pleasant to read in 
> all cases. That is why I suggest to provide tools that allow to 
> customize export accordingly their writing styles.

Maybe then we can simply provide default :export for html and latex, but
nothing else?

> ASCII is a special case since it uses end note style to present link 
> targets.
>
> Whether code is added before link description or after it, either 
> parenthesis are used or not, the following functions may be convenient 
> for Org and for users:
> - export argument as inline source block
> - add an item to ASCII list of links

I wouldn't oppose improving ox-ascii API. Feel free to submit a patch.

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

Re: Exporting elisp: and shell: links

[Rudolf Adamkovič]

Ihor Radchenko <yantar92@posteo.net> writes:

> I am not sure if I like it.

Me neither.  The problem is in the parentheses, IMHO.  The Lisp
expression is enclosed in parentheses and so is the description:

  (message "Hello") (Message Hello)

That indeed looks confusing!  How about we swap the sides and remove one
pair of parentheses?  That would give:

  Message Hello (message "Hello")

Rudy
-- 
"Genius is 1% inspiration and 99% perspiration."
-- Thomas Alva Edison, 1932

Rudolf Adamkovič <salutis@me.com> [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

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]

[-- Attachment #1: Type: text/plain, Size: 1113 bytes --]

Max Nikulin <manikulin@gmail.com> writes:

> On 05/09/2023 16:42, Ihor Radchenko wrote:
>> Max Nikulin writes:
>>>
>>>   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.
>
> Just a guess, likely unrelated to actual decision. For links like 
> "lisp:" or "shell:" keeping link type does not have much sense (however 
> stripping it is questionable as well).
>
>  From my point of view, e.g. <elisp:(identity "a")> should be exported 
> as plain text <code>(identity "a")</code> rather than an (invalid due to 
> not escaped quotes inside href) link <a href="(identity "a")">(identity 
> "a")</a>.
>
> I still believe that fallback export should preserve link type. Code 
> links should define their export functions.

Let's get started on tackling this problem from not stripping the link
type.

I am attaching tentative patch to that effect, as a first step.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-org-export-Do-not-strip-link-type-by-default-during-.patch --]
[-- Type: text/x-patch, Size: 6588 bytes --]

From d0b6d3ff62749aaee40ca37964095bbaa3120128 Mon Sep 17 00:00:00 2001
Message-ID: <d0b6d3ff62749aaee40ca37964095bbaa3120128.1707147647.git.yantar92@posteo.net>
From: Ihor Radchenko <yantar92@posteo.net>
Date: Mon, 5 Feb 2024 16:39:05 +0100
Subject: [PATCH] org-export: Do not strip link type by default during export

* lisp/ox-html.el (org-html-link):
* lisp/ox-latex.el (org-latex-link):
* lisp/ox-man.el (org-man-link):
* lisp/ox-md.el (org-md-link):
* lisp/ox-odt.el (org-odt-link--inline-image):
* lisp/ox-texinfo.el (org-texinfo-link): Preserve link type during
export for all the links, not just for a hard-coded subset.
* etc/ORG-NEWS (Built-in HTML, LaTeX, Man, Markdown, ODT, and Texinfo
exporters preserve the link protocol during export): Document the
breaking change.

Link: https://list.orgmode.org/orgmode/878r9nofpw.fsf@localhost/
---
 etc/ORG-NEWS       | 18 ++++++++++++++++++
 lisp/ox-html.el    |  4 +---
 lisp/ox-latex.el   |  4 +---
 lisp/ox-man.el     |  4 +---
 lisp/ox-md.el      |  4 +---
 lisp/ox-odt.el     |  6 ++----
 lisp/ox-texinfo.el |  4 +---
 7 files changed, 25 insertions(+), 19 deletions(-)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 965872d23..c5e84b7c7 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -13,6 +13,24 @@ Please send Org bug reports to mailto:emacs-orgmode@gnu.org.
 
 * Version 9.7 (not released yet)
 ** Important announcements and breaking changes
+*** Built-in HTML, LaTeX, Man, Markdown, ODT, and Texinfo exporters preserve the link protocol during export
+
+Previously, some link types where not exported as =protocol:uri= but
+as bare =uri=. This is now changed.
+
+When a link is known by Org mode and does not have a custom ~:export~
+parameter (see A.3 Adding Hyperlink Types section of the manual), the
+link protocol is now not stripped.
+
+For example, if one adds a link type =tel=, but does not define
+~:export~ parameter
+: (org-link-set-parameters "tel")
+=[[tel:12345][John Doe]]= link will be correctly exported to LaTeX as
+=\href{tel:12345}{John Doe}=, not =\href{12345}{John Doe}=.
+
+However, links like =[[elisp:(+ 1 2)]]= will be exported as
+=\url{elisp:(+ 1 2)}=, which may be somewhat unexpected.
+
 *** Org mode now fontifies whole table lines (including newline) according to ~org-table~ face
 
 Previously, leading indentation and trailing newline in table rows
diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index 976c24584..9812ac2b7 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -3231,8 +3231,6 @@ (defun org-html-link (link desc info)
 	 (desc (org-string-nw-p desc))
 	 (path
 	  (cond
-	   ((member type '("http" "https" "ftp" "mailto" "news"))
-	    (url-encode-url (concat type ":" raw-path)))
 	   ((string= "file" type)
 	    ;; During publishing, turn absolute file names belonging
 	    ;; to base directory into relative file names.  Otherwise,
@@ -3259,7 +3257,7 @@ (defun org-html-link (link desc info)
 		  (concat raw-path
 			  "#"
 			  (org-publish-resolve-external-link option path t))))))
-	   (t raw-path)))
+	   (t (url-encode-url (concat type ":" raw-path)))))
 	 (attributes-plist
 	  (org-combine-plists
 	   ;; Extract attributes from parent's paragraph.  HACK: Only
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index e3edef3bd..060a01b0e 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -2925,12 +2925,10 @@ (defun org-latex-link (link desc info)
 		  link (plist-get info :latex-inline-image-rules)))
 	 (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)))))
+		   (concat type ":" raw-path))))))
     (cond
      ;; Link type is handled by a special function.
      ((org-export-custom-protocol-maybe link desc 'latex info))
diff --git a/lisp/ox-man.el b/lisp/ox-man.el
index 1f296baeb..16058fb9a 100644
--- a/lisp/ox-man.el
+++ b/lisp/ox-man.el
@@ -614,10 +614,8 @@ (defun org-man-link (link desc info)
          ;; Ensure DESC really exists, or set it to nil.
          (desc (and (not (string= desc "")) desc))
          (path (pcase type
-                 ((or "http" "https" "ftp" "mailto")
-                  (concat type ":" raw-path))
                  ("file" (org-export-file-uri raw-path))
-                 (_ raw-path))))
+                 (_ (concat type ":" raw-path)))))
     (cond
      ;; Link type is handled by a special function.
      ((org-export-custom-protocol-maybe link desc 'man info))
diff --git a/lisp/ox-md.el b/lisp/ox-md.el
index b40d75031..5233ec3eb 100644
--- a/lisp/ox-md.el
+++ b/lisp/ox-md.el
@@ -541,11 +541,9 @@ (defun org-md-link (link desc info)
 	 (type (org-element-property :type link))
 	 (raw-path (org-element-property :path link))
 	 (path (cond
-		((member type '("http" "https" "ftp" "mailto"))
-		 (concat type ":" raw-path))
 		((string-equal  type "file")
 		 (org-export-file-uri (funcall link-org-files-as-md raw-path)))
-		(t raw-path))))
+		(t (concat type ":" raw-path)))))
     (cond
      ;; Link type is handled by a special function.
      ((org-export-custom-protocol-maybe link desc 'md info))
diff --git a/lisp/ox-odt.el b/lisp/ox-odt.el
index f46b25a9a..778cc62cf 100644
--- a/lisp/ox-odt.el
+++ b/lisp/ox-odt.el
@@ -2246,11 +2246,9 @@ (defun org-odt-link--inline-image (element info)
   (cl-assert (org-element-type-p element 'link))
   (let* ((src (let* ((type (org-element-property :type element))
 		     (raw-path (org-element-property :path element)))
-		(cond ((member type '("http" "https"))
-		       (concat type ":" raw-path))
-		      ((file-name-absolute-p raw-path)
+		(cond ((file-name-absolute-p raw-path)
 		       (expand-file-name raw-path))
-		      (t raw-path))))
+		      (t (concat type ":" raw-path)))))
 	 (src-expanded (if (file-name-absolute-p src) src
 			 (expand-file-name src (file-name-directory
 						(plist-get info :input-file)))))
diff --git a/lisp/ox-texinfo.el b/lisp/ox-texinfo.el
index cfbef0c09..f9b73ac6f 100644
--- a/lisp/ox-texinfo.el
+++ b/lisp/ox-texinfo.el
@@ -1321,11 +1321,9 @@ (defun org-texinfo-link (link desc info)
 	 (desc (and (not (string= desc "")) desc))
 	 (path (org-texinfo--sanitize-content
 		(cond
-		 ((member type '("http" "https" "ftp"))
-		  (concat type ":" raw-path))
 		 ((string-equal type "file")
 		  (org-export-file-uri raw-path))
-		 (t raw-path)))))
+		 (t (concat type ":" raw-path))))))
     (cond
      ((org-export-custom-protocol-maybe link desc 'texinfo info))
      ((org-export-inline-image-p link org-texinfo-inline-image-rules)
-- 
2.43.0


[-- Attachment #3: Type: text/plain, Size: 224 bytes --]


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

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]

Ihor Radchenko <yantar92@posteo.net> writes:

>> I still believe that fallback export should preserve link type. Code 
>> links should define their export functions.
>
> Let's get started on tackling this problem from not stripping the link
> type.
>
> I am attaching tentative patch to that effect, as a first step.

Applied, onto main.

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

Re: [DISCUSSION] May we recognize everything like [[protocol:uri]] as a non-fuzzy link? (was: [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/)])

[Max Nikulin]

On 01/09/2023 16:04, Ihor Radchenko wrote:
> And introduce [[::fig:something]] to allow explicit internal links.

I would consider an explicit link type for internal links, e.g. org: or 
o: to allow search links in angle brackets <o:src-block-name> or 
<org:#custom-id>.