At Wed, 07 Sep 2011 16:01:48 +0530, Jambunathan K wrote: > > Hello, > > > > I just realized a diff in behavior between 3 URL entered in the Org buffer > > with slight differences: > > > > - http://web.com/file.php?name=Rep&path=%2FPROJ%2FSomeFile.txt > > This one is correctly exported, but when clicking on it from the Org > > buffer, > > the URL opened in the browser is > > http://web.com/file.php?name=Rep&path=%252FPROJ%252FSomeFile.txt, > > ^^ ^^ > > hence path not found error. > > > > - [[http://web.com/file.php?name=Rep&path=%2FPROJ%2FSomeFile.txt]] > > Works OK in Org and in exported HTML file. > > > > - > > [[http://web.com/file.php?name=Rep&path=%2FPROJ%2FSomeFile.txt][Description]] > > Idem. > > 2. When the Org buffer is exported to html or odt > > ,---- In org-html-handle-links > | (setq path (save-match-data (org-link-unescape <== > | (match-string 3 line)))) > | (setq type (cond > | ((match-end 2) (match-string 2 line)) > | ((save-match-data > | (or (file-name-absolute-p path) > | (string-match "^\\.\\.?/" path))) > | "file") > | (t "internal"))) > | (setq path (org-extract-attributes (org-link-unescape path))) <== > `---- > > link unescape happens twice. Asymmetry due to One link escape + two link > unescape asymmetry creates problem on export. > > Based on historical research, the second org-link-unescape can be > removed. The fact that attributes can be entered at C-c C-l prompt is > largely documented and so the second call to org-link-unescape can > largely be removed.
The three issues (plain links, enter link via C-c C-l, and double-unescape) are not related in a strict sense. I just pushed: - a fix for `org-open-at-point' and plain links; problem was, that in contrast to bracket links the plain link was not unescaped when read from buffer - removed the second `org-link-unescape' in `org-html-handle-links'; PATH is already unescaped, does not change between first and third `setq' and should always be escaped only once. Attached patch is for org-lparse.el. The inconsistency C-c C-l vs. copy'n'paste vs. manually entering a link is under further review. The base problem is, that we (a) need to escape certain characters for Org mode (i.e. square brackets) (b) need to treat links in a Org buffer either as escaped -or- as unescaped; you can't always tell the difference from the string alone (e.g. "%25" could be the escaped percent sign or the unescaped sequence "%25") (c) don't know if the user enters or pastes a escaped or unescaped link; if the user manually enters a link with the sequence "%5B" and we later read that link, we can't tell if it is a bracket escaped by us or a percent escaped bracket in the original link Best, -- David -- OpenPGP... 0x99ADB83B5A4478E6 Jabber.... dmj...@jabber.org Email..... dm...@ictsoc.de
From 66f09f4608dae272a0eac432dd097a00f632f1d6 Mon Sep 17 00:00:00 2001
From: David Maus <dm...@ictsoc.de>
Date: Sun, 11 Sep 2011 16:57:01 +0200
Subject: [PATCH] Remove unecessary link unescape
* org-lparse.el (org-lparse-format-org-link): Remove unecessary link
unescape.
---
contrib/lisp/org-lparse.el | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/lisp/org-lparse.el b/contrib/lisp/org-lparse.el
index 39d9403..a36b0d7 100755
--- a/contrib/lisp/org-lparse.el
+++ b/contrib/lisp/org-lparse.el
@@ -199,7 +199,7 @@ OPT-PLIST is the export options list."
(string-match "^\\.\\.?/" path)))
"file")
(t "internal")))
- (setq path (org-extract-attributes (org-link-unescape path)))
+ (setq path (org-extract-attributes path))
(setq attr (get-text-property 0 'org-attributes path))
(setq desc1 (if (match-end 5) (match-string 5 line))
desc2 (if (match-end 2) (concat type ":" path) path)
--
1.7.2.5
pgpCGmiLOJSAy.pgp
Description: PGP signature
