From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ross Patterson Subject: Re: Org-protocol / Chrome on Linux Date: Thu, 09 Dec 2010 22:44:18 -0800 Message-ID: <87k4jiuny5.fsf@transitory.lefae.org> References: <87aao21i92.fsf@gmx.de> <87hbh7s0da.fsf@gmx.de> <87aamzrzry.fsf@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from [140.186.70.92] (port=40314 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PQwie-0005xN-1m for emacs-orgmode@gnu.org; Fri, 10 Dec 2010 01:44:41 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PQwic-0001dH-By for emacs-orgmode@gnu.org; Fri, 10 Dec 2010 01:44:39 -0500 Received: from lo.gmane.org ([80.91.229.12]:37290) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PQwib-0001d1-Ui for emacs-orgmode@gnu.org; Fri, 10 Dec 2010 01:44:38 -0500 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1PQwiZ-0006Bb-Dc for emacs-orgmode@gnu.org; Fri, 10 Dec 2010 07:44:35 +0100 Received: from 69.12.174.198 ([69.12.174.198]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 10 Dec 2010 07:44:35 +0100 Received: from me by 69.12.174.198 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 10 Dec 2010 07:44:35 +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: emacs-orgmode@gnu.org Mattias Jämting 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 writes: >>> Mattias Jämting 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 >> >>