server.el problem ?

server.el problem ?

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 1701 bytes --]

Hi all,

I wanted to use org-protocol with chrome and emacs-24.1 under windows 7.
I registered the org-protocol protocol with:

[HKEY_CLASSES_ROOT\org-protocol]
@="URL:Org Protocol"
"URL Protocol"=""

[HKEY_CLASSES_ROOT\org-protocol\shell]

[HKEY_CLASSES_ROOT\org-protocol\shell\open]

[HKEY_CLASSES_ROOT\org-protocol\shell\open\command]
@="\"C:\\Local\\Emacs-24.1\\bin\\emacsclientw.exe\" \"-n\" \"%1\""

I added a button to the chrome toolbar with :

javascript:location.href='org-protocol://capture://'+encodeURIComponent(location.href)+'/'+encodeURIComponent(document.title)+'/'+
encodeURIComponent(window.getSelection())

but org-protocol failed to capture anything. The reason was that the
emacsclientw.exe directory was added to the org-protocol url.
I traced the problem to server.el and I had to patch it this way:

@@ -1137,7 +1135,8 @@
                  (let ((file (pop args-left)))
                    (if coding-system
                        (setq file (decode-coding-string file
coding-system)))
-                   (setq file (expand-file-name file dir))
+                   (unless (string-match "^[^/]+:/" file)
+                     (setq file (expand-file-name file dir)))
                    (push (cons file filepos) files)
                    (server-log (format "New file: %s %s"
                                        file (or filepos "")) proc))

to prevent addition of the current directory to the org-protocol url.
This is a crude patch, but anyway, I have the feeling nothing should be
added to 'file' when it is 'absolute' or when it is a url like in this case.

Have I done something wrong? Or is there a problem here ?

Thanks for your comments,
-- 
Fabrice Popineau

[-- Attachment #2: Type: text/html, Size: 3521 bytes --]

Re: server.el problem ?

[Tassilo Horn]

Fabrice Popineau <fabrice.popineau@supelec.fr> writes:

Hi Fabrice,

> javascript:location.href='org-protocol://capture://'+encodeURIComponent(location.href)+'/'+encodeURIComponent(document.title)+'/'+
> encodeURIComponent(window.getSelection())
>
> but org-protocol failed to capture anything. The reason was that the
> emacsclientw.exe directory was added to the org-protocol url.
> I traced the problem to server.el and I had to patch it this way:
>
> [patch]
>
> to prevent addition of the current directory to the org-protocol url.
> This is a crude patch, but anyway, I have the feeling nothing should be
> added to 'file' when it is 'absolute' or when it is a url like in this
> case.
>
> Have I done something wrong? Or is there a problem here ?

Dunno exactly, but at least for me typing

  % emacsclient org-protocol://capture://www.google.de

in a terminal while the emacs server is running opens a new org capture
buffer with a link to www.google.de prefilled, no nothing's added.
AFAIKS, that's exactly what your javascript snippet also does, isn't it?

I run a very recent bzr emacs, so maybe the problem is already solved in
between 24.1 and now...

Bye,
Tassilo

Re: server.el problem ?

[Eli Zaretskii]

> From: Fabrice Popineau <fabrice.popineau@supelec.fr>
> Date: Wed, 1 Aug 2012 14:01:14 +0200
> 
> 
> [1:text/plain Hide]
> 
> Hi all,
> 
> I wanted to use org-protocol with chrome and emacs-24.1 under windows 7.
> I registered the org-protocol protocol with:
> 
> [HKEY_CLASSES_ROOT\org-protocol]
> @="URL:Org Protocol"
> "URL Protocol"=""
> 
> [HKEY_CLASSES_ROOT\org-protocol\shell]
> 
> [HKEY_CLASSES_ROOT\org-protocol\shell\open]
> 
> [HKEY_CLASSES_ROOT\org-protocol\shell\open\command]
> @="\"C:\\Local\\Emacs-24.1\\bin\\emacsclientw.exe\" \"-n\" \"%1\""
> 
> I added a button to the chrome toolbar with :
> 
> javascript:location.href='org-protocol://capture://'+encodeURIComponent(location.href)+'/'+encodeURIComponent(document.title)+'/'+
> encodeURIComponent(window.getSelection())
> 
> but org-protocol failed to capture anything. The reason was that the
> emacsclientw.exe directory was added to the org-protocol url.
> I traced the problem to server.el and I had to patch it this way:
> 
> @@ -1137,7 +1135,8 @@
>                   (let ((file (pop args-left)))
>                     (if coding-system
>                         (setq file (decode-coding-string file coding-system)))
> -                   (setq file (expand-file-name file dir))
> +                   (unless (string-match "^[^/]+:/" file)
> +                     (setq file (expand-file-name file dir)))
>                     (push (cons file filepos) files)
>                     (server-log (format "New file: %s %s"
>                                         file (or filepos "")) proc))
> 
> to prevent addition of the current directory to the org-protocol url.
> This is a crude patch, but anyway, I have the feeling nothing should be
> added to 'file' when it is 'absolute' or when it is a url like in this case.
> 
> Have I done something wrong? Or is there a problem here ?

Are you saying the current code runs a URL through expand-file-name?
If so, I'd say it's sure a bug.  It probably works on Posix platforms
by sheer luck.

Instead of using string-match, perhaps we have a predicate somewhere
that tests strings for being a URL?

Re: server.el problem ?

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 231 bytes --]

>
> AFAIKS, that's exactly what your javascript snippet also does, isn't it?
>
> Yes.


> I run a very recent bzr emacs, so maybe the problem is already solved in
> between 24.1 and now...
>
> I run the trunk version too.

Fabrice

[-- Attachment #2: Type: text/html, Size: 565 bytes --]

Re: server.el problem ?

[Tassilo Horn]

Fabrice Popineau <fabrice.popineau@supelec.fr> writes:

>     AFAIKS, that's exactly what your javascript snippet also does,
>     isn't it?
>     
> Yes.
>
>     I run a very recent bzr emacs, so maybe the problem is already
>     solved in between 24.1 and now...
>     
> I run the trunk version too.

Hm, ok.  Then do you have a concrete URL that triggers the problem for
you?

Bye,
Tassilo

Re: server.el problem ?

[Fabrice Popineau]

[-- Attachment #1: Type: text/plain, Size: 661 bytes --]

>
> Are you saying the current code runs a URL through expand-file-name?
>

It seems so. Moreover :

(expand-file-name "c:/home/.emacs" "c:/temp")
"c:/home/.emacs"
(expand-file-name "http://www.google.fr/foo.html" "c:/home")
"c:/home/http:/www.google.fr/foo.html"
(expand-file-name "org-protocol://capture://www.google.fr/foo.html"
"c:/home")
"c:/home/org-protocol:/capture:/www.google.fr/foo.html"

Emacs currrent trunk (more or less), windows 7, compiled by myself.
Anybody can confirm ?

Instead of using string-match, perhaps we have a predicate somewhere

 that tests strings for being a URL?
>

I'm glad if anybody provides a cleaner patch.


-- 
Fabrice

[-- Attachment #2: Type: text/html, Size: 1531 bytes --]

Re: server.el problem ?

[Tassilo Horn]

Fabrice Popineau <fabrice.popineau@supelec.fr> writes:

>> Are you saying the current code runs a URL through expand-file-name?
>
> It seems so. Moreover :
>
> (expand-file-name "c:/home/.emacs" "c:/temp")
> "c:/home/.emacs"
> (expand-file-name "http://www.google.fr/foo.html" "c:/home")
> "c:/home/http:/www.google.fr/foo.html"
> (expand-file-name "org-protocol://capture://www.google.fr/foo.html"
> "c:/home")
> "c:/home/org-protocol:/capture:/www.google.fr/foo.html"
>
> Emacs currrent trunk (more or less), windows 7, compiled by myself.
> Anybody can confirm ?

Yes (on GNU/Linux), and in fact

  $ emacsclient org-protocol://capture://www.google.fr/foo.html
  $ emacsclient org-protocol://capture://http://www.google.fr/foo.html

doesn't give the correct result because of that.  In my other mail, I
tested

  $ emacsclient org-protocol://capture://www.google.fr

where the problem also exists but doesn't really matter, i.e., the link
is just www.google.fr but org-mode itself is that clever to see its a
URL and does the right thing.

Bye,
Tassilo