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
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
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
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
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
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
.
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
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
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
"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
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
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.
>
>
"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
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
14 matches
Mail list logo
