emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Orgmode] Re: org-protocol: non-ASCII characters


From: Sebastian Rose
Subject: Re: [Orgmode] Re: org-protocol: non-ASCII characters
Date: Mon, 15 Feb 2010 10:41:27 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

Jan Böcker <address@hidden> 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áéíóú.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 
splitparts) "/")))))
+    (let* ((splitparts (split-string uri "/+"))
+           (extraslash "//"))
+      (if (string= "file:" (car splitparts))
+          (setq extraslash "/"))
+      (setq uri (concat (car splitparts) extraslash (mapconcat 'identity (cdr 
splitparts) "/")))))
   uri)



Best wishes,


   Sebastian




reply via email to

[Prev in Thread] Current Thread [Next in Thread]