From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Dokos Subject: Re: [bug] Org link dialog escapes URL spaces incorrectly Date: Fri, 04 Nov 2011 12:52:39 -0400 Message-ID: <24425.1320425559@alphaville.dokosmarshall.org> References: <23807.1320424380@alphaville.dokosmarshall.org> Reply-To: nicholas.dokos@hp.com Return-path: Received: from eggs.gnu.org ([140.186.70.92]:35150) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RMN0X-0002gp-Tk for emacs-orgmode@gnu.org; Fri, 04 Nov 2011 12:52:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RMN0U-0004KR-AV for emacs-orgmode@gnu.org; Fri, 04 Nov 2011 12:52:45 -0400 Received: from g1t0029.austin.hp.com ([15.216.28.36]:43616) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RMN0U-0004KI-3h for emacs-orgmode@gnu.org; Fri, 04 Nov 2011 12:52:42 -0400 In-Reply-To: Message from Nick Dokos of "Fri, 04 Nov 2011 12:33:00 EDT." <23807.1320424380@alphaville.dokosmarshall.org> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Cc: Jeff Horn , Org-mode ml , nicholas.dokos@hp.com Nick Dokos wrote: > Jeff Horn wrote: > > > I just pulled the latest org-mode. The problem persists for me, even > > though it was reported as fixed in a previous thread. Can anyone > > replicate with the latest org? > > > > Org-mode version 7.7 (release_7.7.513.g2a5877) > > GNU Emacs 24.0.50.3 (i386-apple-darwin9.8.0, NS apple-appkit-949.54) > > of 2011-08-10 on braeburn.aquamacs.org - Aquamacs Distribution 3.xdev > > > > On Tue, Nov 1, 2011 at 22:02, Jeff Horn wrote: > > > Org-mode version 7.7 (release_7.7.404.ga17c.dirty) > > > GNU Emacs 24.0.50.3 (i386-apple-darwin9.8.0, NS apple-appkit-949.54) > > > of 2011-08-10 on braeburn.aquamacs.org - Aquamacs Distribution 3.xdev > > > > > > Inserting a link through the link dialog doesn't escape URLs with > > > spaces properly. Where a space is '%20', org will insert the link as > > > '%2520'. I'm not certain of URL escape codes, but could org be trying > > > to escape the % sign? Perhaps a missing slash in a regexp somewhere? > > > > > > 1) Use =C-c C-l= to use dialog. Paste a link, like the following. > > > > > > http://www.dartmouth.edu/~dirwin/Did%20France%20Cause%20the%20Great%20Depression.pdf > > > > > > 2) Use =C-c C-o= to open the link. Be weirded out about a 404. Inspect URL. > > > > > > ,----[ Actual ] > > > | - [ ] [[http://www.dartmouth.edu/~dirwin/Did%2520France%2520Cause%2520the%2520Great%2520Depression.pdf][Link > > > Description]] > > > `---- > > > > > > ,----[ Expected ] > > > | - [ ] [[http://www.dartmouth.edu/~dirwin/Did%20France%20Cause%20the%20Great%20Depression.pdf][Link > > > Description]] > > > `---- > > > > > The problem is in org-insert-link: in one case, when we edit the link at point, > the link is unescaped: > > ,---- > | ... > | ((org-in-regexp org-bracket-link-regexp 1) > | ;; We do have a link at point, and we are going to edit it. > | (setq remove (list (match-beginning 0) (match-end 0))) > | (setq desc (if (match-end 3) (org-match-string-no-properties 3))) > | (setq link (read-string "Link: " > | (org-link-unescape > | (org-match-string-no-properties 1))))) > `---- > > but in the other case, when we just paste the link into the minibuffer, > it is not - check from the (unwind-protect ... ) on line 9088 of org.el > and ff to the end of the function: the link that's read from the minibuffer > is passed untouched (well, at least unescaped) to org-make-link-string on > the very last line of the function and apparently the latter reescapes everything: > try replacing the call > > (org-make-link-string link desc) > > on the last line of org-insert-link with > > (org-make-link-string (org-link-unescape link) desc) > > I think that'll fix it. > It probably does, but that's probably not the best place to do it: it might be better to do it in the (setq link on line 9090 or thereabouts. Otherwise, in the *other* case (editing the link at point), we'll end up unescaping twice: probably not a problem, since unescaping should be idempotent (in contrast to escaping ;-) ) but why do it twice? Nick