From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sebastian Rose Subject: Re: Re: org-protocol: non-ASCII characters Date: Mon, 15 Feb 2010 10:41:27 +0100 Message-ID: <87aava25vc.fsf@gmx.de> References: <86tyu2d5xw.fsf@mn.cs.uvic.ca> <4B693FBD.9010608@jboecker.de> <86d40k9702.fsf_-_@mn.cs.uvic.ca> <4B6D73A2.8000403@jboecker.de> <4B6D7E1A.3030807@jboecker.de> <878wb4rmm6.fsf@gmx.de> <16e9be801002121423y5bdff5bdy2e9e7503f8deb154@mail.gmail.com> <4B76A791.1090808@jboecker.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NgxSQ-0000nJ-Tk for emacs-orgmode@gnu.org; Mon, 15 Feb 2010 04:41:34 -0500 Received: from [140.186.70.92] (port=57163 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NgxSP-0000mj-Mm for emacs-orgmode@gnu.org; Mon, 15 Feb 2010 04:41:34 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NgxSO-0006pT-Ep for emacs-orgmode@gnu.org; Mon, 15 Feb 2010 04:41:33 -0500 Received: from mail.gmx.net ([213.165.64.20]:59310) by eggs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1NgxSO-0006pF-2q for emacs-orgmode@gnu.org; Mon, 15 Feb 2010 04:41:32 -0500 In-Reply-To: <4B76A791.1090808@jboecker.de> ("Jan =?utf-8?Q?B=C3=B6cker=22?= =?utf-8?Q?'s?= message of "Sat, 13 Feb 2010 14:22:25 +0100") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Jan =?utf-8?Q?B=C3=B6cker?= Cc: emacs-orgmode , dmg Jan B=C3=B6cker writes: > On 12.02.2010 23:23, dmg wrote: > >> For evince, I think I have found a problem in the parsing of the link. >> Evince already encodes >> the URL, but it does not encode the '/', hence you will get a link like = this: >> >> emacsclient 'org-protocol://remember://docview/tmp/00%C3%A1%C3%A9%C3%AD%= C3%B3%C3%BA.pdf::1' >> >> the filename is /tmp/00=C3=A1=C3=A9=C3=AD=C3=B3=C3=BA.pdf >> >> But emacs incorrectly stops parsing the link after tmp/ > > I think I have found the proper way to handle this in evince. > Check out the attached patch or pull from: > > git://github.com/jboecker/evince.git > > This code first retrieves the non-URI-encoded UTF-8 filename and passes > that to uri_encode. Should g_file_get_path return NULL, we abort, > because the URI specifies something in gnomes VFS layer that has no > local path, so the link would not work, anyway. > >> By the way, xournal now supports store-link > > Works as advertised, thanks! > > The only problem I have left now is a cosmetic one: when I store a link > to, say, /tmp/test.xoj, in Org it becomes file://tmp/test.xoj instead of > file:/tmp/test.xoj. (I have patched xournal and evince to generate file: > instead of docview: links.) > > This is because org-protocol-sanitize-uri is called after decoding the > string, allegedly because emacsclient compresses multiple slashes in a > row to one. However, it seems that this function should be applied > /before/ the string is URL-decoded. Is this a bug? Hm - yes and no :) I did not want to expose to much of the encoding and decoding problem to the users. It's already complicated enough to add a bookmarklet. `org-protocol-sanitize-uri' just works for the usual bookmarking and remembering stuff we used it for - and everyone used it for `http:' and similar protocols. How about exending `org-protocol-sanitize-uri' to detect certain protocols like `file:' and drop the extra slash for those? Or, better, add an extra slash, which would be the correct way to express an absolute path (though most apps on Linux these days take `file:/one/slash/only'). org-protocol could be used for other purposes, too. Shouldn't Org-mode follow links like [[file:///absolute/path]] and [[file://absolute/path]] as we would expect? (OK, I know, emacsclient should be fixed...) This is, what my browsers here do. They both do not care for the number of slashes. Opera 10 changes a correct URI to it's own special URI (note the `localhost'): file://localhost/home Firefox takes the `correct' URI: file:///home/sebastian Here is a patch, that would fix it. We could add more exceptions to the if-statement as needed. diff --git a/lisp/org-protocol.el b/lisp/org-protocol.el index 9881e9f..b80131c 100644 --- a/lisp/org-protocol.el +++ b/lisp/org-protocol.el @@ -267,8 +267,11 @@ Here is an example: "emacsclient compresses double and tripple slashes. Slashes are sanitized to double slashes here." (when (string-match "^\\([a-z]+\\):/" uri) - (let* ((splitparts (split-string uri "/+"))) - (setq uri (concat (car splitparts) "//" (mapconcat 'identity (cdr sp= litparts) "/"))))) + (let* ((splitparts (split-string uri "/+")) + (extraslash "//")) + (if (string=3D "file:" (car splitparts)) + (setq extraslash "/")) + (setq uri (concat (car splitparts) extraslash (mapconcat 'identity (= cdr splitparts) "/"))))) uri) Best wishes, Sebastian