* [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/)]
@ 2023-08-31 15:25 Csepp
2023-09-01 2:44 ` Max Nikulin
0 siblings, 1 reply; 33+ messages in thread
From: Csepp @ 2023-08-31 15:25 UTC (permalink / raw)
To: emacs-orgmode
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/)
^ permalink raw reply [flat|nested] 33+ messages in thread
* 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/)]
2023-08-31 15:25 [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
@ 2023-09-01 2:44 ` Max Nikulin
2023-09-01 9:04 ` [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
0 siblings, 1 reply; 33+ messages in thread
From: Max Nikulin @ 2023-09-01 2:44 UTC (permalink / raw)
To: Csepp, emacs-orgmode
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.
^ permalink raw reply [flat|nested] 33+ messages in thread
* [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/)])
2023-09-01 2:44 ` Max Nikulin
@ 2023-09-01 9:04 ` Ihor Radchenko
2023-09-01 10:49 ` Dr. Arne Babenhauserheide
` (4 more replies)
0 siblings, 5 replies; 33+ messages in thread
From: Ihor Radchenko @ 2023-09-01 9:04 UTC (permalink / raw)
To: Max Nikulin, Bastien, Timothy, Tom Gillespie; +Cc: Csepp, emacs-orgmode
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>
^ permalink raw reply [flat|nested] 33+ messages in thread
* 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/)])
2023-09-01 9:04 ` [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
@ 2023-09-01 10:49 ` Dr. Arne Babenhauserheide
2023-09-01 11:01 ` Ihor Radchenko
2023-09-01 12:15 ` [DISCUSSION] May we recognize everything like [[protocol:uri]] as a non-fuzzy link? Jens Lechtenboerger
` (3 subsequent siblings)
4 siblings, 1 reply; 33+ messages in thread
From: Dr. Arne Babenhauserheide @ 2023-09-01 10:49 UTC (permalink / raw)
To: Ihor Radchenko
Cc: Max Nikulin, Bastien, Timothy, Tom Gillespie, Csepp, emacs-orgmode
[-- 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 --]
^ permalink raw reply [flat|nested] 33+ messages in thread
* 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/)])
2023-09-01 10:49 ` Dr. Arne Babenhauserheide
@ 2023-09-01 11:01 ` Ihor Radchenko
2023-09-01 12:25 ` Dr. Arne Babenhauserheide
0 siblings, 1 reply; 33+ messages in thread
From: Ihor Radchenko @ 2023-09-01 11:01 UTC (permalink / raw)
To: Dr. Arne Babenhauserheide
Cc: Max Nikulin, Bastien, Timothy, Tom Gillespie, Csepp, emacs-orgmode
"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>
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [DISCUSSION] May we recognize everything like [[protocol:uri]] as a non-fuzzy link?
2023-09-01 9:04 ` [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
2023-09-01 10:49 ` Dr. Arne Babenhauserheide
@ 2023-09-01 12:15 ` Jens Lechtenboerger
2023-09-02 7:29 ` Ihor Radchenko
2023-09-01 18:53 ` [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
` (2 subsequent siblings)
4 siblings, 1 reply; 33+ messages in thread
From: Jens Lechtenboerger @ 2023-09-01 12:15 UTC (permalink / raw)
To: Ihor Radchenko
Cc: Max Nikulin, Bastien, Timothy, Tom Gillespie, Csepp, emacs-orgmode
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* 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/)])
2023-09-01 11:01 ` Ihor Radchenko
@ 2023-09-01 12:25 ` Dr. Arne Babenhauserheide
2023-09-02 7:26 ` Ihor Radchenko
0 siblings, 1 reply; 33+ messages in thread
From: Dr. Arne Babenhauserheide @ 2023-09-01 12:25 UTC (permalink / raw)
To: Ihor Radchenko
Cc: Max Nikulin, Bastien, Timothy, Tom Gillespie, Csepp, emacs-orgmode
[-- 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 --]
^ permalink raw reply [flat|nested] 33+ messages in thread
* 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/)])
2023-09-01 9:04 ` [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
2023-09-01 10:49 ` Dr. Arne Babenhauserheide
2023-09-01 12:15 ` [DISCUSSION] May we recognize everything like [[protocol:uri]] as a non-fuzzy link? Jens Lechtenboerger
@ 2023-09-01 18:53 ` Tom Gillespie
2023-09-02 7:45 ` Ihor Radchenko
2023-09-02 12:00 ` [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
2023-09-04 15:08 ` [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
4 siblings, 1 reply; 33+ messages in thread
From: Tom Gillespie @ 2023-09-01 18:53 UTC (permalink / raw)
To: Ihor Radchenko, Dr. Arne Babenhauserheide
Cc: Max Nikulin, Bastien, Timothy, Csepp, emacs-orgmode
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* 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/)])
2023-09-01 12:25 ` Dr. Arne Babenhauserheide
@ 2023-09-02 7:26 ` Ihor Radchenko
2023-09-02 7:54 ` Dr. Arne Babenhauserheide
2023-09-04 14:58 ` Max Nikulin
0 siblings, 2 replies; 33+ messages in thread
From: Ihor Radchenko @ 2023-09-02 7:26 UTC (permalink / raw)
To: Dr. Arne Babenhauserheide
Cc: Max Nikulin, Bastien, Timothy, Tom Gillespie, Csepp, emacs-orgmode
"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>
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: [DISCUSSION] May we recognize everything like [[protocol:uri]] as a non-fuzzy link?
2023-09-01 12:15 ` [DISCUSSION] May we recognize everything like [[protocol:uri]] as a non-fuzzy link? Jens Lechtenboerger
@ 2023-09-02 7:29 ` Ihor Radchenko
0 siblings, 0 replies; 33+ messages in thread
From: Ihor Radchenko @ 2023-09-02 7:29 UTC (permalink / raw)
To: Jens Lechtenboerger
Cc: Max Nikulin, Bastien, Timothy, Tom Gillespie, Csepp, emacs-orgmode
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>
^ permalink raw reply [flat|nested] 33+ messages in thread
* 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/)])
2023-09-01 18:53 ` [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
@ 2023-09-02 7:45 ` Ihor Radchenko
0 siblings, 0 replies; 33+ messages in thread
From: Ihor Radchenko @ 2023-09-02 7:45 UTC (permalink / raw)
To: Tom Gillespie
Cc: Dr. Arne Babenhauserheide, Max Nikulin, Bastien, Timothy, Csepp,
emacs-orgmode
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>
^ permalink raw reply [flat|nested] 33+ messages in thread
* 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/)])
2023-09-02 7:26 ` Ihor Radchenko
@ 2023-09-02 7:54 ` Dr. Arne Babenhauserheide
2023-09-04 14:58 ` Max Nikulin
1 sibling, 0 replies; 33+ messages in thread
From: Dr. Arne Babenhauserheide @ 2023-09-02 7:54 UTC (permalink / raw)
To: Ihor Radchenko
Cc: Max Nikulin, Bastien, Timothy, Tom Gillespie, Csepp, emacs-orgmode
[-- 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 --]
^ permalink raw reply [flat|nested] 33+ messages in thread
* [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/)]
2023-09-01 9:04 ` [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
` (2 preceding siblings ...)
2023-09-01 18:53 ` [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
@ 2023-09-02 12:00 ` Max Nikulin
2023-09-03 7:53 ` Ihor Radchenko
2023-09-04 15:08 ` [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
4 siblings, 1 reply; 33+ messages in thread
From: Max Nikulin @ 2023-09-02 12:00 UTC (permalink / raw)
To: emacs-orgmode
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.
^ permalink raw reply [flat|nested] 33+ messages in thread
* 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/)]
2023-09-02 12:00 ` [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
@ 2023-09-03 7:53 ` Ihor Radchenko
2023-09-04 10:51 ` Max Nikulin
0 siblings, 1 reply; 33+ messages in thread
From: Ihor Radchenko @ 2023-09-03 7:53 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
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>
^ permalink raw reply [flat|nested] 33+ messages in thread
* 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/)]
2023-09-03 7:53 ` Ihor Radchenko
@ 2023-09-04 10:51 ` Max Nikulin
2023-09-05 9:42 ` Ihor Radchenko
0 siblings, 1 reply; 33+ messages in thread
From: Max Nikulin @ 2023-09-04 10:51 UTC (permalink / raw)
To: emacs-orgmode
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.
^ permalink raw reply [flat|nested] 33+ messages in thread
* 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/)])
2023-09-02 7:26 ` Ihor Radchenko
2023-09-02 7:54 ` Dr. Arne Babenhauserheide
@ 2023-09-04 14:58 ` Max Nikulin
2023-09-05 11:02 ` Ihor Radchenko
1 sibling, 1 reply; 33+ messages in thread
From: Max Nikulin @ 2023-09-04 14:58 UTC (permalink / raw)
To: emacs-orgmode
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.
^ permalink raw reply [flat|nested] 33+ messages in thread
* 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/)])
2023-09-01 9:04 ` [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
` (3 preceding siblings ...)
2023-09-02 12:00 ` [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
@ 2023-09-04 15:08 ` Max Nikulin
4 siblings, 0 replies; 33+ messages in thread
From: Max Nikulin @ 2023-09-04 15:08 UTC (permalink / raw)
To: emacs-orgmode
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>.
^ permalink raw reply [flat|nested] 33+ messages in thread
* 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/)]
2023-09-04 10:51 ` Max Nikulin
@ 2023-09-05 9:42 ` Ihor Radchenko
2023-09-10 4:40 ` Max Nikulin
0 siblings, 1 reply; 33+ messages in thread
From: Ihor Radchenko @ 2023-09-05 9:42 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
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>
^ permalink raw reply [flat|nested] 33+ messages in thread
* 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/)])
2023-09-04 14:58 ` Max Nikulin
@ 2023-09-05 11:02 ` Ihor Radchenko
2023-09-06 14:27 ` Max Nikulin
0 siblings, 1 reply; 33+ messages in thread
From: Ihor Radchenko @ 2023-09-05 11:02 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
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>
^ permalink raw reply [flat|nested] 33+ messages in thread
* 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/)])
2023-09-05 11:02 ` Ihor Radchenko
@ 2023-09-06 14:27 ` Max Nikulin
2023-09-07 10:42 ` Ihor Radchenko
0 siblings, 1 reply; 33+ messages in thread
From: Max Nikulin @ 2023-09-06 14:27 UTC (permalink / raw)
To: emacs-orgmode
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.
^ permalink raw reply [flat|nested] 33+ messages in thread
* 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/)])
2023-09-06 14:27 ` Max Nikulin
@ 2023-09-07 10:42 ` Ihor Radchenko
2023-09-07 11:07 ` Max Nikulin
0 siblings, 1 reply; 33+ messages in thread
From: Ihor Radchenko @ 2023-09-07 10:42 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
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>
^ permalink raw reply [flat|nested] 33+ messages in thread
* 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/)])
2023-09-07 10:42 ` Ihor Radchenko
@ 2023-09-07 11:07 ` Max Nikulin
2023-09-07 11:22 ` Ihor Radchenko
0 siblings, 1 reply; 33+ messages in thread
From: Max Nikulin @ 2023-09-07 11:07 UTC (permalink / raw)
To: emacs-orgmode
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.
^ permalink raw reply [flat|nested] 33+ messages in thread
* 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/)])
2023-09-07 11:07 ` Max Nikulin
@ 2023-09-07 11:22 ` Ihor Radchenko
0 siblings, 0 replies; 33+ messages in thread
From: Ihor Radchenko @ 2023-09-07 11:22 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
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>
^ permalink raw reply [flat|nested] 33+ messages in thread
* 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/)]
2023-09-05 9:42 ` Ihor Radchenko
@ 2023-09-10 4:40 ` Max Nikulin
2023-09-17 22:08 ` Rudolf Adamkovič
0 siblings, 1 reply; 33+ messages in thread
From: Max Nikulin @ 2023-09-10 4:40 UTC (permalink / raw)
To: emacs-orgmode
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.
^ permalink raw reply [flat|nested] 33+ messages in thread
* 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/)]
2023-09-10 4:40 ` Max Nikulin
@ 2023-09-17 22:08 ` Rudolf Adamkovič
2023-09-18 15:20 ` Exporting elisp: and shell: links Max Nikulin
0 siblings, 1 reply; 33+ messages in thread
From: Rudolf Adamkovič @ 2023-09-17 22:08 UTC (permalink / raw)
To: Max Nikulin, emacs-orgmode
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Exporting elisp: and shell: links
2023-09-17 22:08 ` Rudolf Adamkovič
@ 2023-09-18 15:20 ` Max Nikulin
2023-09-19 0:10 ` Rudolf Adamkovič
0 siblings, 1 reply; 33+ messages in thread
From: Max Nikulin @ 2023-09-18 15:20 UTC (permalink / raw)
To: emacs-orgmode
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
"a")">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?).
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Exporting elisp: and shell: links
2023-09-18 15:20 ` Exporting elisp: and shell: links Max Nikulin
@ 2023-09-19 0:10 ` Rudolf Adamkovič
2023-09-19 15:19 ` Max Nikulin
0 siblings, 1 reply; 33+ messages in thread
From: Rudolf Adamkovič @ 2023-09-19 0:10 UTC (permalink / raw)
To: Max Nikulin, emacs-orgmode
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Exporting elisp: and shell: links
2023-09-19 0:10 ` Rudolf Adamkovič
@ 2023-09-19 15:19 ` Max Nikulin
2023-09-21 9:49 ` Ihor Radchenko
0 siblings, 1 reply; 33+ messages in thread
From: Max Nikulin @ 2023-09-19 15:19 UTC (permalink / raw)
To: emacs-orgmode
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.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Exporting elisp: and shell: links
2023-09-19 15:19 ` Max Nikulin
@ 2023-09-21 9:49 ` Ihor Radchenko
2023-09-22 23:43 ` Rudolf Adamkovič
0 siblings, 1 reply; 33+ messages in thread
From: Ihor Radchenko @ 2023-09-21 9:49 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
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>
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Exporting elisp: and shell: links
2023-09-21 9:49 ` Ihor Radchenko
@ 2023-09-22 23:43 ` Rudolf Adamkovič
2023-09-25 14:38 ` Max Nikulin
0 siblings, 1 reply; 33+ messages in thread
From: Rudolf Adamkovič @ 2023-09-22 23:43 UTC (permalink / raw)
To: Ihor Radchenko, Max Nikulin; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Exporting elisp: and shell: links
2023-09-22 23:43 ` Rudolf Adamkovič
@ 2023-09-25 14:38 ` Max Nikulin
2023-09-26 10:42 ` Ihor Radchenko
0 siblings, 1 reply; 33+ messages in thread
From: Max Nikulin @ 2023-09-25 14:38 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Exporting elisp: and shell: links
2023-09-25 14:38 ` Max Nikulin
@ 2023-09-26 10:42 ` Ihor Radchenko
2023-09-28 15:31 ` Rudolf Adamkovič
0 siblings, 1 reply; 33+ messages in thread
From: Ihor Radchenko @ 2023-09-26 10:42 UTC (permalink / raw)
To: Max Nikulin; +Cc: emacs-orgmode
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>
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Exporting elisp: and shell: links
2023-09-26 10:42 ` Ihor Radchenko
@ 2023-09-28 15:31 ` Rudolf Adamkovič
0 siblings, 0 replies; 33+ messages in thread
From: Rudolf Adamkovič @ 2023-09-28 15:31 UTC (permalink / raw)
To: Ihor Radchenko, Max Nikulin; +Cc: emacs-orgmode
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
^ permalink raw reply [flat|nested] 33+ messages in thread
end of thread, other threads:[~2023-09-28 15:33 UTC | newest]
Thread overview: 33+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-08-31 15:25 [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
2023-09-01 2:44 ` Max Nikulin
2023-09-01 9:04 ` [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
2023-09-01 10:49 ` Dr. Arne Babenhauserheide
2023-09-01 11:01 ` Ihor Radchenko
2023-09-01 12:25 ` Dr. Arne Babenhauserheide
2023-09-02 7:26 ` Ihor Radchenko
2023-09-02 7:54 ` Dr. Arne Babenhauserheide
2023-09-04 14:58 ` Max Nikulin
2023-09-05 11:02 ` Ihor Radchenko
2023-09-06 14:27 ` Max Nikulin
2023-09-07 10:42 ` Ihor Radchenko
2023-09-07 11:07 ` Max Nikulin
2023-09-07 11:22 ` Ihor Radchenko
2023-09-01 12:15 ` [DISCUSSION] May we recognize everything like [[protocol:uri]] as a non-fuzzy link? Jens Lechtenboerger
2023-09-02 7:29 ` Ihor Radchenko
2023-09-01 18:53 ` [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
2023-09-02 7:45 ` Ihor Radchenko
2023-09-02 12:00 ` [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
2023-09-03 7:53 ` Ihor Radchenko
2023-09-04 10:51 ` Max Nikulin
2023-09-05 9:42 ` Ihor Radchenko
2023-09-10 4:40 ` Max Nikulin
2023-09-17 22:08 ` Rudolf Adamkovič
2023-09-18 15:20 ` Exporting elisp: and shell: links Max Nikulin
2023-09-19 0:10 ` Rudolf Adamkovič
2023-09-19 15:19 ` Max Nikulin
2023-09-21 9:49 ` Ihor Radchenko
2023-09-22 23:43 ` Rudolf Adamkovič
2023-09-25 14:38 ` Max Nikulin
2023-09-26 10:42 ` Ihor Radchenko
2023-09-28 15:31 ` Rudolf Adamkovič
2023-09-04 15:08 ` [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
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).