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-03-12 Thread Ihor Radchenko 
Ihor Radchenko  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 .
Support Org development at ,
or support my work at

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 Thread Ihor Radchenko 
Max Nikulin  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.  should be exported 
> as plain text (identity "a") rather than an (invalid due to 
> not escaped quotes inside href) link (identity 
> "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.

>From d0b6d3ff62749aaee40ca37964095bbaa3120128 Mon Sep 17 00:00:00 2001
Message-ID: 
From: Ihor Radchenko 
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.

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-17 Thread Rudolf Adamkovič 
Max Nikulin  writes:

> From my point of view, e.g.  should be exported 
> as plain text (identity "a") rather than an (invalid due to 
> not escaped quotes inside href) link (identity 
> "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č  [he/him]
Studenohorská 25
84103 Bratislava
Slovakia

Re: [BUG] URI handling is overly complicated and nonstandard [9.6.7 (N/A @ /gnu/store/mg7223g8mw90lccp6mm5g6f3mpjk70si-emacs-org-9.6.7/share/emacs/site-lisp/org-9.6.7/)]

2023-09-09 Thread Max Nikulin 

On 05/09/2023 16:42, Ihor Radchenko wrote:

Max Nikulin writes:


  From my point of view it will be more sane behavior. However it may
require update of 3rd party ox backends.


Yes. The main problem is that I fail to understand the motivation behind
the current behaviour. git logs reveal that the code is there from the
initial version of the library.


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


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


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

Re: [BUG] URI handling is overly complicated and nonstandard [9.6.7 (N/A @ /gnu/store/mg7223g8mw90lccp6mm5g6f3mpjk70si-emacs-org-9.6.7/share/emacs/site-lisp/org-9.6.7/)]

2023-09-05 Thread Ihor Radchenko 
Max Nikulin  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 '' 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 .
Support Org development at ,
or support my work at

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 Thread Max Nikulin 

On 03/09/2023 14:53, Ihor Radchenko wrote:

Max Nikulin writes:

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

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

...

\href{321}{call}

"tel:" is missed.


I have realized that it is possible to take advantage of current behavior:

  (org-link-set-parameters
   "browse"
   :follow
   (lambda (url arg) (browse-url url arg)))

so [[browse:tel:+321][call]] with *any* protocol is properly exported 
and opened. The only inconvenience is that the "browse:" type must be 
added when a link is inserted or stripped down to copy a URL.



(path (org-latex--protect-text
(pcase type
  ((or "http" "https" "ftp" "mailto" "doi")
   (concat type ":" raw-path))
  ("file"
   (org-export-file-uri raw-path))
  (_
   raw-path

is fishy.


I do not like that lists of types in ox backends are not the same as in 
ol.el:


(dolist (scheme '("ftp" "http" "https" "mailto" "news"))
  (org-link-set-parameters scheme


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

Does it make sense?


From my point of view it will be more sane behavior. However it may 
require update of 3rd party ox backends.



Actually I had in mind more flexible delegation. :export functions
should be able to alter URI, attributes and to provide description if it
is missed, but did not care if '' or '\href{}{}' should
be used.


I'd call that :filter rather than :export :)


It is an option, the only disadvantage is that `org-link-properties' can 
not set an export filter directly.



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


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



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


Sorry, but I do not understand what you are referring to.
May you elaborate?


My reading of the bug report subject is that it should be easy to define 
a link type for a protocol not supported by Org mode out of the box. 
Minimal features are export and follow using a handler configured 
desktop-wide or Emacs-wide.

Re: [BUG] URI handling is overly complicated and nonstandard [9.6.7 (N/A @ /gnu/store/mg7223g8mw90lccp6mm5g6f3mpjk70si-emacs-org-9.6.7/share/emacs/site-lisp/org-9.6.7/)]

2023-09-03 Thread Ihor Radchenko 
Max Nikulin  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 '' 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 .
Support Org development at ,
or support my work at

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 Thread Max Nikulin 

On 31/08/2023 22:25, Csepp wrote:

There seems to be no easy way to tell it
to just treat it the same way it would treat an HTTP link and include it
verbatim.  There does seem to be a way to do some Elisp scripting, but
it's honestly really annoying to do this for every protocol type.

Please, just let users include URLs in their docs.


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

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


So it is possible to have custom link types.

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


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