Clicking on URL does convert some special characters

Clicking on URL does convert some special characters

[Sebastien Vauban]

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.

Best regards,
  Seb

-- 
Sebastien Vauban

Re: Clicking on URL does convert some special characters

[Jambunathan K]

> 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.

Same as or 99% similar to
https://lists.gnu.org/archive/html/emacs-orgmode/2011-08/msg00513.html

1. When link is entered through C-c C-l org unescapes it. As a result
   the link in the buffer IS DIFFERENT from the entered URL.

   This is a CRITICAL bug.

,---- In org-insert-link
|
|       (setq link (read-string "Link: "
| 			      (org-link-unescape
| 			       (org-match-string-no-properties 1))))
`----

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.

Jambunathan K.

   
       
   



> Best regards,
>   Seb

-- 

Re: Clicking on URL does convert some special characters

[David Maus]

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

At Wed, 07 Sep 2011 11:20:03 +0200,
Sebastien Vauban 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.

I'll look into this. Looks like the plain link is escaped before
passed to the browser.

Best,
  -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber.... dmjena@jabber.org
Email..... dmaus@ictsoc.de

[-- Attachment #2: Type: application/pgp-signature, Size: 230 bytes --]

Re: Clicking on URL does convert some special characters

[Sebastien Vauban]

Hi David,

David Maus wrote:
> At Wed, 07 Sep 2011 11:20:03 +0200,
> Sebastien Vauban wrote:
>> 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.
>
> I'll look into this. Looks like the plain link is escaped before
> passed to the browser.

Exactly what seems to happen, yes.

Thanks for looking into that!

Best regards,
  Seb

-- 
Sebastien Vauban

Re: Clicking on URL does convert some special characters

[David Maus]

[-- Attachment #1.1: Type: text/plain, Size: 2918 bytes --]

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.... dmjena@jabber.org
Email..... dmaus@ictsoc.de

[-- Attachment #1.2: 0001-Remove-unecessary-link-unescape.patch --]
[-- Type: text/plain, Size: 977 bytes --]

From 66f09f4608dae272a0eac432dd097a00f632f1d6 Mon Sep 17 00:00:00 2001
From: David Maus <dmaus@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


[-- Attachment #2: Type: application/pgp-signature, Size: 230 bytes --]

Re: Clicking on URL does convert some special characters

[Jambunathan K]

I have committed this patch. Can someone remove this from the
patchwork's pending queue.

http://patchwork.newartisans.com/patch/940/

Re: Clicking on URL does convert some special characters

[Carsten Dominik]

Done, thanks.

- Carsten

On 9.10.2011, at 10:12, Jambunathan K wrote:

> 
> I have committed this patch. Can someone remove this from the
> patchwork's pending queue.
> 
> http://patchwork.newartisans.com/patch/940/
> 
> 
>