emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Ross Patterson <me@rpatterson.net>
To: emacs-orgmode@gnu.org
Subject: Re: Org-protocol / Chrome on Linux
Date: Thu, 09 Dec 2010 22:44:18 -0800	[thread overview]
Message-ID: <87k4jiuny5.fsf@transitory.lefae.org> (raw)
In-Reply-To: AANLkTimr4Vu3TuD_uDt=D-s33cB9V6DVLNy9WmkBGtyb@mail.gmail.com

Mattias Jämting <mattias@jwd.se> 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 <sebastian_rose@gmx.de>:
>> Sebastian Rose <sebastian_rose@gmx.de> writes:
>>> Mattias Jämting <mattias@jwd.se> 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.
>>>>
>>>> mattias@helium:~$ xdg-open org-protocol://capture://http%3A%2F%2Forgmode.org
>>>> Error showing URL: Operation not supported
>>>> mattias@helium:~$ xdg-open org-protocol://capture://http://orgmode.org>>> mattias@helium:~$ (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:
>>
>> mattias@helium:~$ emacsclient org-protocol://capture://http%3A%2F%2Forgmode.org
>>
>>
>> works.
>>
>>
>>  Sebastian
>>
>>

      reply	other threads:[~2010-12-10  6:44 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-31 17:20 Org-protocol / Chrome on Linux Mattias Jämting
2010-08-31 23:20 ` Sebastian Rose
2010-09-30 13:11   ` Mattias Jämting
2010-09-30 15:43     ` Sebastian Rose
2010-09-30 15:56       ` Sebastian Rose
2010-11-24 23:23         ` Mattias Jämting
2010-12-10  6:44           ` Ross Patterson [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87k4jiuny5.fsf@transitory.lefae.org \
    --to=me@rpatterson.net \
    --cc=emacs-orgmode@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).