* [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; 43+ 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] 43+ 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; 43+ 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] 43+ 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; 43+ 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] 43+ 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; 43+ 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] 43+ 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; 43+ 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] 43+ 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; 43+ 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] 43+ 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; 43+ 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] 43+ 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; 43+ 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] 43+ 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; 43+ 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] 43+ 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; 43+ 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] 43+ 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; 43+ 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] 43+ 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; 43+ 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] 43+ 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; 43+ 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] 43+ 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; 43+ 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] 43+ 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; 43+ 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] 43+ 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; 43+ 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] 43+ 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; 43+ 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] 43+ 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; 43+ 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] 43+ 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; 43+ 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] 43+ 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; 43+ 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] 43+ 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; 43+ 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] 43+ 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; 43+ 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] 43+ 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č 2024-02-05 15:41 ` [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, 2 replies; 43+ 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] 43+ 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 2024-02-05 15:41 ` [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 1 sibling, 1 reply; 43+ 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] 43+ 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; 43+ 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] 43+ 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; 43+ 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] 43+ 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; 43+ 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] 43+ 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; 43+ 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] 43+ 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; 43+ 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] 43+ 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; 43+ 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] 43+ 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; 43+ 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] 43+ messages in thread
* Re: Exporting elisp: and shell: links 2023-09-26 10:42 ` Ihor Radchenko @ 2023-09-28 15:31 ` Rudolf Adamkovič 2023-10-08 9:48 ` Ihor Radchenko 0 siblings, 1 reply; 43+ 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] 43+ messages in thread
* Re: Exporting elisp: and shell: links 2023-09-28 15:31 ` Rudolf Adamkovič @ 2023-10-08 9:48 ` Ihor Radchenko 2023-10-09 12:04 ` Max Nikulin 2023-10-11 19:34 ` Rudolf Adamkovič 0 siblings, 2 replies; 43+ messages in thread From: Ihor Radchenko @ 2023-10-08 9:48 UTC (permalink / raw) To: Rudolf Adamkovič; +Cc: Max Nikulin, emacs-orgmode [-- 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> ^ permalink raw reply related [flat|nested] 43+ messages in thread
* Re: Exporting elisp: and shell: links 2023-10-08 9:48 ` Ihor Radchenko @ 2023-10-09 12:04 ` Max Nikulin 2023-10-09 12:12 ` Ihor Radchenko 2023-10-11 19:34 ` Rudolf Adamkovič 1 sibling, 1 reply; 43+ messages in thread From: Max Nikulin @ 2023-10-09 12:04 UTC (permalink / raw) To: emacs-orgmode 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. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Exporting elisp: and shell: links 2023-10-09 12:04 ` Max Nikulin @ 2023-10-09 12:12 ` Ihor Radchenko 2023-10-10 10:35 ` Max Nikulin 0 siblings, 1 reply; 43+ messages in thread From: Ihor Radchenko @ 2023-10-09 12:12 UTC (permalink / raw) To: Max Nikulin; +Cc: emacs-orgmode 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> ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Exporting elisp: and shell: links 2023-10-09 12:12 ` Ihor Radchenko @ 2023-10-10 10:35 ` Max Nikulin 2023-10-12 11:35 ` Ihor Radchenko 0 siblings, 1 reply; 43+ messages in thread From: Max Nikulin @ 2023-10-10 10:35 UTC (permalink / raw) To: emacs-orgmode 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. ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Exporting elisp: and shell: links 2023-10-10 10:35 ` Max Nikulin @ 2023-10-12 11:35 ` Ihor Radchenko 2023-10-13 10:20 ` Max Nikulin 0 siblings, 1 reply; 43+ messages in thread From: Ihor Radchenko @ 2023-10-12 11:35 UTC (permalink / raw) To: Max Nikulin; +Cc: emacs-orgmode 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> ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Exporting elisp: and shell: links 2023-10-12 11:35 ` Ihor Radchenko @ 2023-10-13 10:20 ` Max Nikulin 2023-10-14 8:13 ` Ihor Radchenko 0 siblings, 1 reply; 43+ messages in thread From: Max Nikulin @ 2023-10-13 10:20 UTC (permalink / raw) To: emacs-orgmode 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 ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Exporting elisp: and shell: links 2023-10-13 10:20 ` Max Nikulin @ 2023-10-14 8:13 ` Ihor Radchenko 0 siblings, 0 replies; 43+ messages in thread From: Ihor Radchenko @ 2023-10-14 8:13 UTC (permalink / raw) To: Max Nikulin; +Cc: emacs-orgmode 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> ^ permalink raw reply [flat|nested] 43+ messages in thread
* Re: Exporting elisp: and shell: links 2023-10-08 9:48 ` Ihor Radchenko 2023-10-09 12:04 ` Max Nikulin @ 2023-10-11 19:34 ` Rudolf Adamkovič 1 sibling, 0 replies; 43+ messages in thread From: Rudolf Adamkovič @ 2023-10-11 19:34 UTC (permalink / raw) To: Ihor Radchenko; +Cc: Max Nikulin, emacs-orgmode 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 ^ permalink raw reply [flat|nested] 43+ 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č @ 2024-02-05 15:41 ` Ihor Radchenko 2024-03-12 11:00 ` Ihor Radchenko 1 sibling, 1 reply; 43+ messages in thread From: Ihor Radchenko @ 2024-02-05 15:41 UTC (permalink / raw) To: Max Nikulin; +Cc: emacs-orgmode [-- 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> ^ permalink raw reply related [flat|nested] 43+ 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/)] 2024-02-05 15:41 ` [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 @ 2024-03-12 11:00 ` Ihor Radchenko 0 siblings, 0 replies; 43+ messages in thread From: Ihor Radchenko @ 2024-03-12 11:00 UTC (permalink / raw) To: Max Nikulin; +Cc: emacs-orgmode 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> ^ permalink raw reply [flat|nested] 43+ 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; 43+ 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] 43+ messages in thread
end of thread, other threads:[~2024-03-12 10:57 UTC | newest] Thread overview: 43+ 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-10-08 9:48 ` Ihor Radchenko 2023-10-09 12:04 ` Max Nikulin 2023-10-09 12:12 ` Ihor Radchenko 2023-10-10 10:35 ` Max Nikulin 2023-10-12 11:35 ` Ihor Radchenko 2023-10-13 10:20 ` Max Nikulin 2023-10-14 8:13 ` Ihor Radchenko 2023-10-11 19:34 ` Rudolf Adamkovič 2024-02-05 15:41 ` [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 2024-03-12 11:00 ` 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
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).
![[-- Attachment #2: html-without-diff.png --] [-- Type: image/png, Size: 10838 bytes --]](../../87r0m5phrc.fsf@localhost/2-html-without-diff.png){kind=link}
![[-- Attachment #4: html-with-diff.png --] [-- Type: image/png, Size: 13552 bytes --]](../../87r0m5phrc.fsf@localhost/4-html-with-diff.png){kind=link}