emacs-orgmode
[Top][All Lists]
Advanced

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

[Orgmode] Re: Org-protocol / Chrome on Linux


From: Ross Patterson
Subject: [Orgmode] Re: Org-protocol / Chrome on Linux
Date: Thu, 09 Dec 2010 22:44:18 -0800
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1.50 (gnu/linux)

Mattias Jämting <address@hidden> writes:

> Hello again,
>
> For reference, this is how i finally got org-protocol to work in
> chrome on ubuntu 10.10:
>
> The problem was that chrome was running xdg-open for handling external
> protocols. xdg-open, or it's companion gvfs-open, couldn't parse the
> rather complex URL which the org-capture bookmarklet generated.

I found a minimal test case and filed a bug for this:

https://bugs.launchpad.net/ubuntu/+source/libgnome/+bug/688436

The key to this is that using "%2F" in the URL *path* causes gvfs-open
and gnome-open to raise an error.

    $ gvfs-open "http://foo.com/bar%2Fqux";
    gvfs-open: http://foo.com/bar%2Fqux: error opening location: Operation not 
supported

While this is a bug in those packages, I've always thought the
org-protocol URL format was problematic.  Why not use URL query args
instead?  Note that gvfs-open and gnome-open handle that just fine:

    $ gvfs-open "http://foo.com?blah=bar%2Fqux";

It seems like org-protocol would have fewer edge case problems and would
have URLs that would make more sense to more people if we used URL query
args instead:

     
org-protocol://store-link?URL=http%3A%2F%2Ffoo.com&TITLE=Bar%20Qux&BODY=blah%20blah

If this sounds good, I'd be happy to submit patches for this.  Provided
there's something available in emacs for parsing URL query args.

Ross

> So i realized that xdg-open is just a shell-script so  then i modified
> the function open-gnome() in it like this:
>
> open_gnome()
> {
>     # Handle org-protocol
>     if (echo "$1" | grep -q '^org-protocol://'); then
>       emacsclient "$1"
>     else      
>         # This is the standard way...
>         if gvfs-open --help 2>/dev/null 1>&2; then
>             gvfs-open "$1"
>       else
>             gnome-open "$1"
>         fi
>     fi
>     ...
> }
>
> Suddenly all works. Remember to back-up xdg-open if you want to try this.
>
> Mattias
>
> 2010/9/30 Sebastian Rose <address@hidden>:
>> Sebastian Rose <address@hidden> writes:
>>> Mattias Jämting <address@hidden> writes:
>>>> Yes i'm running a pretty standard Ubuntu 10.04 setup.
>>>>
>>>> I managed to get it working on chrome by removing the
>>>> encodeURIComponent command on location.href.
>>>>
>>>> I could simulate it in the terminal like this.
>>>>
>>>> address@hidden:~$ xdg-open 
>>>> org-protocol://capture://http%3A%2F%2Forgmode.org
>>>> Error showing URL: Operation not supported
>>>> address@hidden:~$ xdg-open org-protocol://capture://http://orgmode.org>>> 
>>>> address@hidden:~$ (worked)
>>>>
>>>> Strange that it worked in FF. Maybe Chrome and FF encodes URIs differently?
>>>
>>>
>>> Ooops!
>>>
>>> I just was going to blame Google.
>>>
>>> Looking into the ECMA standard, I found this:
>>>
>>> 15.1.3 URI Handling Function Properties
>>>
>>>        ... ...
>>>
>>>        A URI is composed of a sequence of components separated by
>>>        component separators. The general form
>>>        is:
>>>                  Scheme : First / Second ; Third ? Fourth
>>>
>>>        where the italicised names represent components and the “:”, “/”,
>>>        “;” and “?” are reserved characters used as separators. The
>>>        encodeURI and decodeURI functions are intended to work with
>>>        complete URIs; they assume that any reserved characters in the
>>>        URI are intended to have special meaning and so are not
>>>        encoded. The encodeURIComponent and decodeURIComponent functions
>>>        are intended to work with the individual component parts of a
>>>        URI; they assume that any reserved characters represent text and
>>>        so must be encoded so that they are not interpreted as reserved
>>>        characters when the component is part of a complete URI.
>>>
>>>
>>> That document states "encodeURI" is to be used with complete URIs (as
>>> the name says...).  Funny.  Chrome is the only browser that works like
>>> that :)
>>>
>>> I'll go and adjust the docs.
>>>
>>>
>>> Thanks for your Report!!
>>>
>>
>>
>>
>> Actually --- errr --- there is nothing to adjust.  The docs are exactly
>> right.
>>
>> This is because of some örfflkjsgs in xdg-open.
>>
>> No one ever said something about xdg-open.  Org-protocol is supposed to
>> work with emacsclient:
>>
>> address@hidden:~$ emacsclient 
>> org-protocol://capture://http%3A%2F%2Forgmode.org
>>
>>
>> works.
>>
>>
>>  Sebastian
>>
>>




reply via email to

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