bug#16751: 24.3.50; Export during Org export to HTML

bug#16751: 24.3.50; Export during Org export to HTML

[Bastien]

Eli Zaretskii <eliz@gnu.org> writes:

> Ugh.  Bastien, could you (or someone else of Org developers) please
> look into this?  Why does the URI above causes the recent version of
> Org to pass an invalid file name such as
>
>    ///opt/tomcat/4/apache-tomcat-4.1.40/... to expand-file-name

I will look into this, but I can't promise anything before next week.

Thanks for the heads up,

-- 
 Bastien

bug#16751: 24.3.50; Export during Org export to HTML

[Eli Zaretskii]

> From: Bastien <bzg@altern.org>
> Cc: Sebastien Vauban <sva-news@mygooglest.com>,  16751@debbugs.gnu.org
> Date: Tue, 25 Feb 2014 18:12:05 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Ugh.  Bastien, could you (or someone else of Org developers) please
> > look into this?  Why does the URI above causes the recent version of
> > Org to pass an invalid file name such as
> >
> >    ///opt/tomcat/4/apache-tomcat-4.1.40/... to expand-file-name
> 
> I will look into this, but I can't promise anything before next week.

Thanks.  There's no rush.  I will fix expand-file-name so it doesn't
crash with such bogus file names.

bug#16751: 24.3.50; Export during Org export to HTML

[Nicolas Goaziou]

Hello,

Bastien <bzg@altern.org> writes:

>> Ugh.  Bastien, could you (or someone else of Org developers) please
>> look into this?  Why does the URI above causes the recent version of
>> Org to pass an invalid file name such as
>>
>>    ///opt/tomcat/4/apache-tomcat-4.1.40/... to expand-file-name
>
> I will look into this, but I can't promise anything before next week.
>
> Thanks for the heads up,

A quick analysis.

    file:path

is a valid file link type in Org. Therefore,

    file:///opt/tomcat/4/apache-tomcat-4.1.40/webapps/../user_projects/GHIJSP2/deploy/WEB-INF/sharedfiles/resources/FR/domVal.xml

is parsed as a file link with path:

    ///opt/tomcat/4/apache-tomcat-4.1.40/webapps/../user_projects/GHIJSP2/deploy/WEB-INF/sharedfiles/resources/FR/domVal.xml

This path passes `file-name-absolute-p' predicate, so "ox-html.el"
concatenates "file://" to

  (expand-file-name path)

Since path is absolute, per `file-name-absolute-p', `expand-file-name'
is probably needed for its "and canonicalize it" part.

Note that other export back-ends, like, "ox-md.el", also use this
construct.

FWIW, I don't see any wrong behaviour here (except that "file://" should
probably not be prepended to path in this case).


Regards,

-- 
Nicolas Goaziou

bug#16751: 24.3.50; Export during Org export to HTML

[Eli Zaretskii]

> From: Nicolas Goaziou <n.goaziou@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Sebastien Vauban <sva-news@mygooglest.com>,  16751@debbugs.gnu.org
> Date: Tue, 25 Feb 2014 19:04:10 +0100
> 
> >> Ugh.  Bastien, could you (or someone else of Org developers) please
> >> look into this?  Why does the URI above causes the recent version of
> >> Org to pass an invalid file name such as
> >>
> >>    ///opt/tomcat/4/apache-tomcat-4.1.40/... to expand-file-name
> >
> > I will look into this, but I can't promise anything before next week.
> >
> > Thanks for the heads up,
> 
> A quick analysis.
> 
>     file:path
> 
> is a valid file link type in Org. Therefore,
> 
>     file:///opt/tomcat/4/apache-tomcat-4.1.40/webapps/../user_projects/GHIJSP2/deploy/WEB-INF/sharedfiles/resources/FR/domVal.xml
> 
> is parsed as a file link with path:
> 
>     ///opt/tomcat/4/apache-tomcat-4.1.40/webapps/../user_projects/GHIJSP2/deploy/WEB-INF/sharedfiles/resources/FR/domVal.xml

But that's exactly the problem: producing a file name from a file://
URL requires to remove the "file://" prefix.  It is invalid to leave
the 2 extra slashes and remove only "file:".  Why does Org do that?

> FWIW, I don't see any wrong behaviour here (except that "file://" should
> probably not be prepended to path in this case).

Now I'm confused: why are you talking about prepending "file://", when
the problem, as I understand it, happens because "file://" was not
_removed_ from it together with the 2 slashes?

bug#16751: 24.3.50; Export during Org export to HTML

[Glenn Morris]

Eli Zaretskii wrote:

>>     file:path
>> 
>> is a valid file link type in Org. Therefore,
[...]
> But that's exactly the problem: producing a file name from a file://
> URL requires to remove the "file://" prefix.  It is invalid to leave
> the 2 extra slashes and remove only "file:".  Why does Org do that?

Presumably because Org decided to use "file:" rather than standard
"file://" URI, hence leading to exactly this confusion.

Re: bug#16751: 24.3.50; Export during Org export to HTML

[Achim Gratz]

Eli Zaretskii writes:
> But that's exactly the problem: producing a file name from a file://
> URL requires to remove the "file://" prefix.  It is invalid to leave
> the 2 extra slashes and remove only "file:".  Why does Org do that?

Because Org doesn't know squat about URI schemes and uses ad-hoc parsing
and manipulation rather than splicing it all out according to the spec.

Besides, why is three leading slashes even a problem?  IIRC, POSIX says
that any number of leading slashes (except when starting with exactly
two, which are system dependent and are usually interpreted as a UNC
path) should do exactly the same thing as a single slash.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra

bug#16751: 24.3.50; Export during Org export to HTML

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: Nicolas Goaziou <n.goaziou@gmail.com>,  sva-news@mygooglest.com,  bzg@altern.org,  16751@debbugs.gnu.org
> Date: Tue, 25 Feb 2014 13:41:14 -0500
> 
> Eli Zaretskii wrote:
> 
> >>     file:path
> >> 
> >> is a valid file link type in Org. Therefore,
> [...]
> > But that's exactly the problem: producing a file name from a file://
> > URL requires to remove the "file://" prefix.  It is invalid to leave
> > the 2 extra slashes and remove only "file:".  Why does Org do that?
> 
> Presumably because Org decided to use "file:" rather than standard
> "file://" URI, hence leading to exactly this confusion.

That cannot be right, though, can it?  If Org wants to support
file:/foo, fine, but then it should try the standard file:///foo
before falling back on non-standard forms, I think.  Am I missing
something?

bug#16751: 24.3.50; Export during Org export to HTML

[Eli Zaretskii]

> Date: Tue, 25 Feb 2014 19:49:02 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: sva-news@mygooglest.com, 16751@debbugs.gnu.org
> 
> > From: Bastien <bzg@altern.org>
> > Cc: Sebastien Vauban <sva-news@mygooglest.com>,  16751@debbugs.gnu.org
> > Date: Tue, 25 Feb 2014 18:12:05 +0100
> > 
> > Eli Zaretskii <eliz@gnu.org> writes:
> > 
> > > Ugh.  Bastien, could you (or someone else of Org developers) please
> > > look into this?  Why does the URI above causes the recent version of
> > > Org to pass an invalid file name such as
> > >
> > >    ///opt/tomcat/4/apache-tomcat-4.1.40/... to expand-file-name
> > 
> > I will look into this, but I can't promise anything before next week.
> 
> Thanks.  There's no rush.  I will fix expand-file-name so it doesn't
> crash with such bogus file names.

I fixed expand-file-name (trunk revision 116624).  I'm keeping the bug
open until the Org part is either fixed or we decide it doesn't need
fixing.

bug#16751: 24.3.50; Export during Org export to HTML

[Bastien]

Hi Eli,

Eli Zaretskii <eliz@gnu.org> writes:

> I fixed expand-file-name (trunk revision 116624).

Thanks.

> I'm keeping the bug open until the Org part is either fixed or we
> decide it doesn't need fixing.

In my opinion, it needs a fix, but it's quite a rewrite, so don't
expect any change here before Org 9.0.

If someone wants to work on this, help is welcome.

Let's keep the bug open in the meantime.

-- 
 Bastien

bug#16751: 24.3.50; Export during Org export to HTML

[Nicolas Goaziou]

[-- Attachment #1: Type: text/plain, Size: 232 bytes --]

Hello,

Bastien <bzg@gnu.org> writes:

> If someone wants to work on this, help is welcome.

> Let's keep the bug open in the meantime.

Unless I'm mistaken, the following patch should fix the issue.


Regards,

-- 
Nicolas Goaziou

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Make-Org-links-compatible-with-URI-syntax.patch --]
[-- Type: text/x-diff, Size: 4138 bytes --]

From 4d62387fe035d9aa3d1dc96d12d40c53dca2afe5 Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou <n.goaziou@gmail.com>
Date: Fri, 28 Mar 2014 19:24:38 +0100
Subject: [PATCH] Make Org links compatible with URI syntax

* lisp/org.el (org-make-link-regexps): Allow optional double slashes
  after type.  Small refactoring.

* testing/lisp/test-org-element.el (test-org-element/link-parser):
  Update test.

This patch allows to write both [[file:/file.org]] and [[file:///file.org]].
See bug#16751.
---
 lisp/org.el                      | 43 ++++++++++++++++++----------------------
 testing/lisp/test-org-element.el |  6 ++----
 2 files changed, 21 insertions(+), 28 deletions(-)

diff --git a/lisp/org.el b/lisp/org.el
index bb83eb7..53f142e 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -5658,34 +5658,29 @@ stacked delimiters is N.  Escaping delimiters is not possible."
   "Update the link regular expressions.
 This should be called after the variable `org-link-types' has changed."
   (setq org-link-types-re
-	(concat
-	 "\\`\\(" (mapconcat 'regexp-quote org-link-types "\\|") "\\):")
+	(concat "\\`" (regexp-opt org-link-types t) ":\\(?://\\)")
 	org-link-re-with-space
-	(concat
-	 "<?\\(" (mapconcat 'regexp-quote org-link-types "\\|") "\\):"
-	 "\\([^" org-non-link-chars " ]"
-	 "[^" org-non-link-chars "]*"
-	 "[^" org-non-link-chars " ]\\)>?")
+	(concat "<?" (regexp-opt org-link-types t) ":\\(?://\\)"
+		"\\([^" org-non-link-chars " ]"
+		"[^" org-non-link-chars "]*"
+		"[^" org-non-link-chars " ]\\)>?")
 	org-link-re-with-space2
-	(concat
-	 "<?\\(" (mapconcat 'regexp-quote org-link-types "\\|") "\\):"
-	 "\\([^" org-non-link-chars " ]"
-	 "[^\t\n\r]*"
-	 "[^" org-non-link-chars " ]\\)>?")
+	(concat "<?" (regexp-opt org-link-types t) ":\\(?://\\)?"
+		"\\([^" org-non-link-chars " ]"
+		"[^\t\n\r]*"
+		"[^" org-non-link-chars " ]\\)>?")
 	org-link-re-with-space3
-	(concat
-	 "<?\\(" (mapconcat 'regexp-quote org-link-types "\\|") "\\):"
-	 "\\([^" org-non-link-chars " ]"
-	 "[^\t\n\r]*\\)")
+	(concat "<?" (regexp-opt org-link-types t) ":\\(?://\\)?"
+		"\\([^" org-non-link-chars " ]"
+		"[^\t\n\r]*\\)")
 	org-angle-link-re
-	(concat
-	 "<\\(" (mapconcat 'regexp-quote org-link-types "\\|") "\\):"
-	 "\\([^" org-non-link-chars " ]"
-	 "[^" org-non-link-chars "]*"
-	 "\\)>")
+	(concat "<" (regexp-opt org-link-types t) ":\\(?://\\)?"
+		"\\([^" org-non-link-chars " ]"
+		"[^" org-non-link-chars "]*"
+		"\\)>")
 	org-plain-link-re
 	(concat
-	 "\\<\\(" (mapconcat 'regexp-quote org-link-types "\\|") "\\):"
+	 "\\<" (regexp-opt org-link-types t) ":\\(?://\\)?"
 	 (org-re "\\([^ \t\n()<>]+\\(?:([[:word:]0-9_]+)\\|\\([^[:punct:] \t\n]\\|/\\)\\)\\)"))
 	;;	 "\\([^]\t\n\r<>() ]+[^]\t\n\r<>,.;() ]\\)")
 	org-bracket-link-regexp
@@ -5693,7 +5688,7 @@ This should be called after the variable `org-link-types' has changed."
 	org-bracket-link-analytic-regexp
 	(concat
 	 "\\[\\["
-	 "\\(\\(" (mapconcat 'regexp-quote org-link-types "\\|") "\\):\\)?"
+	 "\\(" (regexp-opt org-link-types t) ":\\(?://\\)?\\)?"
 	 "\\([^]]+\\)"
 	 "\\]"
 	 "\\(\\[" "\\([^]]+\\)" "\\]\\)?"
@@ -5701,7 +5696,7 @@ This should be called after the variable `org-link-types' has changed."
 	org-bracket-link-analytic-regexp++
 	(concat
 	 "\\[\\["
-	 "\\(\\(" (mapconcat 'regexp-quote (cons "coderef" org-link-types) "\\|") "\\):\\)?"
+	 "\\(" (regexp-opt (cons "coderef" org-link-types) t) ":\\(?://\\)?\\)?"
 	 "\\([^]]+\\)"
 	 "\\]"
 	 "\\(\\[" "\\([^]]+\\)" "\\]\\)?"
diff --git a/testing/lisp/test-org-element.el b/testing/lisp/test-org-element.el
index def1659..72eea22 100644
--- a/testing/lisp/test-org-element.el
+++ b/testing/lisp/test-org-element.el
@@ -1362,12 +1362,10 @@ e^{i\\pi}+1=0
   ;; ... with expansion.
   (should
    (equal
-    "//orgmode.org/worg"
+    "orgmode.org/worg"
     (org-test-with-temp-text "[[Org:worg]]"
       (let ((org-link-abbrev-alist '(("Org" . "http://orgmode.org/"))))
-	(org-element-property
-	 :path
-	 (org-element-map (org-element-parse-buffer) 'link 'identity nil t))))))
+	(org-element-property :path (org-element-context))))))
   ;; ... with translation.
   (should
    (equal
-- 
1.9.1

bug#16751: 24.3.50; Export during Org export to HTML

[Nicolas Goaziou]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Unless I'm mistaken, the following patch should fix the issue.

Applied.

-- 
Nicolas Goaziou

bug#16751: 24.3.50; Export during Org export to HTML

[Bastien]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Nicolas Goaziou <n.goaziou@gmail.com> writes:
>
>> Unless I'm mistaken, the following patch should fix the issue.
>
> Applied.

Thanks!

-- 
 Bastien