[O] bug#16751: 24.3.50; Export during Org export to HTML
Nicolas Goaziou writes: > Nicolas Goaziou writes: > >> Unless I'm mistaken, the following patch should fix the issue. > > Applied. Thanks! -- Bastien
[O] bug#16751: 24.3.50; Export during Org export to HTML
Nicolas Goaziou writes: > Unless I'm mistaken, the following patch should fix the issue. Applied. -- Nicolas Goaziou
[O] bug#16751: 24.3.50; Export during Org export to HTML
Hello,
Bastien 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
>From 4d62387fe035d9aa3d1dc96d12d40c53dca2afe5 Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou
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
- "?")
+ (concat "?")
org-link-re-with-space2
- (concat
- "?")
+ (concat "?")
org-link-re-with-space3
- (concat
- "")
+ (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
[O] bug#16751: 24.3.50; Export during Org export to HTML
Hi Eli, Eli Zaretskii 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
[O] bug#16751: 24.3.50; Export during Org export to HTML
> Date: Tue, 25 Feb 2014 19:49:02 +0200 > From: Eli Zaretskii > Cc: sva-n...@mygooglest.com, 16...@debbugs.gnu.org > > > From: Bastien > > Cc: Sebastien Vauban , 16...@debbugs.gnu.org > > Date: Tue, 25 Feb 2014 18:12:05 +0100 > > > > Eli Zaretskii 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.
[O] bug#16751: 24.3.50; Export during Org export to HTML
> From: Glenn Morris > Cc: Nicolas Goaziou , sva-n...@mygooglest.com, > b...@altern.org, 16...@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?
Re: [O] bug#16751: 24.3.50; Export during Org export to HTML
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
[O] bug#16751: 24.3.50; Export during Org export to HTML
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.
[O] bug#16751: 24.3.50; Export during Org export to HTML
> From: Nicolas Goaziou > Cc: Eli Zaretskii , Sebastien Vauban > , 16...@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?
[O] bug#16751: 24.3.50; Export during Org export to HTML
Hello, Bastien 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
[O] bug#16751: 24.3.50; Export during Org export to HTML
> From: Bastien > Cc: Sebastien Vauban , 16...@debbugs.gnu.org > Date: Tue, 25 Feb 2014 18:12:05 +0100 > > Eli Zaretskii 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.
[O] bug#16751: 24.3.50; Export during Org export to HTML
Eli Zaretskii 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
