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

[Ihor Radchenko]

Max Nikulin  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 .
Support Org development at ,
or support my work at 

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

[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/mg7223g8mw90lccp6mm5g6f3

[Ihor Radchenko]

Max Nikulin  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 .
Support Org development at ,
or support my work at 

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

[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/mg7223g8mw90lccp6mm5g6f3

[Ihor Radchenko]

Max Nikulin  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 .
Support Org development at ,
or support my work at 

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

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

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

[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/mg7223g8mw90lccp6mm5g6f3

[Dr. Arne Babenhauserheide]

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


signature.asc
Description: PGP signature

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

[Ihor Radchenko]

Tom Gillespie  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- 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:



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://bracket-link.com]]

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

The angle link works all the time, unconditionally parsing 
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 .
Support Org development at ,
or support my work at 

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

[Ihor Radchenko]

"Dr. Arne Babenhauserheide"  writes:

>> May you elaborate about what is going to be broken?
>
> I have many links where I use <> 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 .
Support Org development at ,
or support my work at 

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

[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- 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/mg7223g8mw90lccp6mm5g6f3

[Dr. Arne Babenhauserheide]

Ihor Radchenko  writes:

> "Dr. Arne Babenhauserheide"  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 <> 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


signature.asc
Description: PGP signature

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

[Ihor Radchenko]

"Dr. Arne Babenhauserheide"  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 .
Support Org development at ,
or support my work at 

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

[Dr. Arne Babenhauserheide]

Ihor Radchenko  writes:

> In theory, we might change the parser to treat anything like foo:bar or
>  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


signature.asc
Description: PGP signature