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

[Jan Böcker]

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?

0001-bugfix-in-encode_uri-cast-to-unsigned-char-to-get-th.patch
Description: Text document

0002-URI-encode-the-utf-8-filename-instead-of-a-partially.patch
Description: Text document