[O] bug#16751: 24.3.50; Export during Org export to HTML
Nicolas Goaziou n.goaz...@gmail.com writes: Nicolas Goaziou n.goaz...@gmail.com 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 n.goaz...@gmail.com 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 b...@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
From 4d62387fe035d9aa3d1dc96d12d40c53dca2afe5 Mon Sep 17 00:00:00 2001
From: Nicolas Goaziou n.goaz...@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
[O] bug#16751: 24.3.50; Export during Org export to HTML
Hi Eli, Eli Zaretskii e...@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
[O] bug#16751: 24.3.50; Export during Org export to HTML
Date: Tue, 25 Feb 2014 19:49:02 +0200 From: Eli Zaretskii e...@gnu.org Cc: sva-n...@mygooglest.com, 16...@debbugs.gnu.org From: Bastien b...@altern.org Cc: Sebastien Vauban sva-n...@mygooglest.com, 16...@debbugs.gnu.org Date: Tue, 25 Feb 2014 18:12:05 +0100 Eli Zaretskii e...@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.
[O] bug#16751: 24.3.50; Export during Org export to HTML
Eli Zaretskii e...@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
[O] bug#16751: 24.3.50; Export during Org export to HTML
From: Bastien b...@altern.org Cc: Sebastien Vauban sva-n...@mygooglest.com, 16...@debbugs.gnu.org Date: Tue, 25 Feb 2014 18:12:05 +0100 Eli Zaretskii e...@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.
[O] bug#16751: 24.3.50; Export during Org export to HTML
Hello, Bastien b...@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
[O] bug#16751: 24.3.50; Export during Org export to HTML
From: Nicolas Goaziou n.goaz...@gmail.com Cc: Eli Zaretskii e...@gnu.org, Sebastien Vauban sva-n...@mygooglest.com, 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
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: [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
From: Glenn Morris r...@gnu.org Cc: Nicolas Goaziou n.goaz...@gmail.com, 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?
