org-protocol: deal with broken links on windows

org-protocol: deal with broken links on windows

[Ingo Lohmar]

Dear all,

It appears that org-capture (with the no-frills, no-extensions method of
adding a registry entry for org-protocol) using new-style links is not
working correctly on Windows (tested with recent Firefoxes as well as
the Chromium derivative Iridium).

What happens is that the browser binary with full path is prepended to
the protocol, and an extra "/" is added before the URL query string.
That is, what *should* read

  org-protocol:/capture?template=y&url=http%3A%2F%2Fjira%2Fbrowse%2FSDST-705&title=SOMETHING

is actually passed as 

  c:/Program Files/Iridium/58.0.0.0/org-protocol:/capture/?template=y&url=http%3A%2F%2Fjira%2Fbrowse%2FSDST-705&title=SOMETHING

as the FNAME argument to `org-protocol-check-filename-for-protocol'.  I
have no idea what brought about this crazy change, but I've long ago
stopped trying to understand Windows' ways --- nowadays I just lobby
against using it.

Anyway, I've successfully (regular use for several weeks) patched this
with an advice:

>------------------------------------------------------------------------------<

(defun adv/sanitize-broken-windows-link (args)
  (let ((fname (car args)))
    (cons
     (if (string-match "^[a-z]:/[-a-zA-Z0-9 /._]+/\\(org-protocol:/[^/\\?]*\\)/\\(\\?.*\\)$" fname)
         (concat (match-string 1 fname) (match-string 2 fname))
       fname)
     (cdr args))))
(advice-add #'org-protocol-check-filename-for-protocol :filter-args #'adv/sanitize-broken-windows-link)

>------------------------------------------------------------------------------<

I only use this on the Windows machine, where FNAME reliably has the
above form for me (probably better ONLY use it when (eq system-type
'windows-nt)).  Also, the regexp is probably too unspecific even on
Windows.  Could we still add this or an improved transformation of FNAME
to `org-protocol-check-filename-for-protocol' (assuming there's no
better way)?

Thank you!

Ingo

Re: org-protocol: deal with broken links on windows

[Nikolay Kudryavtsev]

I've recently set up org-protocol as well and while I can confirm that 
it prepends the full executable path, I don't get the extra "/" and 
org-protocol works fine. And your link worked fine, except that I had to 
obviously change the template name. From what I understand the addition  
of that "/" is extremely weird, since protocol just passes the whole 
string to the command.

What version of org are you using? I'm currently using org-9.0.9 
installed from a zip.

And to be sure maybe you should try something like:

emacsclientw.exe 
"org-protocol:/capture?template=w&url=http%3A%2F%2Fjira%2Fbrowse%2FSDST-705&title=SOMETHING&body="

-- 
Best Regards,
Nikolay Kudryavtsev

Re: org-protocol: deal with broken links on windows

[Ingo Lohmar]

Hi Nikolay,

Thanks for your reply.  I checked a few things today: I am using Org
mode version 9.0.9 (9.0.9-82-gb862c2-elpaplus,
org-plus-contrib-20170814/) and the unofficial emacs build GNU Emacs
25.2.1 (x86_64-w64-mingw32) of 2017-04-24 from
http://sourceforge.net/projects/emacsbinw64/ (supposedly straight from
original sources).

> emacsclientw.exe 
> "org-protocol:/capture?template=w&url=http%3A%2F%2Fjira%2Fbrowse%2FSDST-705&title=SOMETHING&body="

1) Without any patch/advice, calling emacsclientw directly on this
   address (modulo template letter) works fine, as does a call with the
   full executable path.  I think the path prefix is weird, but fine
   with me.  The culprit (independent of the prefix) is the "/" before
   the query string.  So thanks for narrowing this down, first of all.

2) Just a side note: store-link (instead of capture) shows the exact same behavior.

3) Here are the bookmarklets I use...

>------------------------------------------------------------------------------<
javascript:location.href='org-protocol://store-link?url='+encodeURIComponent(location.href)+'&title='+encodeURIComponent(document.title)+'&body='+encodeURIComponent(window.getSelection())

javascript:location.href='org-protocol://capture?template=y&url='+encodeURIComponent(location.href)+'&title='+encodeURIComponent(document.title)+'&body='+encodeURIComponent(window.getSelection())
>------------------------------------------------------------------------------<

4) ...and the registry entries

>------------------------------------------------------------------------------<
REGEDIT4

[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:\\Program Files\\Emacs\\bin\\emacsclientw.exe\" --no-wait \"%1\""
>------------------------------------------------------------------------------<

I think this is all as it should be, and I have tried to make the
minimal changes to get a working system.

5) Soooooo the remaining puzzle:

How can the "/" get in there?  As I said, it happens when called from
both FF (although I have not used that for a few weeks now) and Iridium.
It seems to happen somewhere b/w the browser and emacsclientw, ie, in
the Windows "protocol" handling, I suppose?

If other people can confirm (or even explain) this behavior, we could
decide if there should be a transformation on the FNAME argument.  In
that case, it should definitely leave the leading executable path alone.

Thanks a lot so far!
Ingo

Re: org-protocol: deal with broken links on windows

[Nikolay Kudryavtsev]

Hello Ingo.

Sorry my bad, I've ran into exactly the same bug before, just I 
originally didn't notice that "/" before the query is exactly the thing, 
that brings everything down, but I still suspected it to be the same bug.

Your problem is that your bookmarklets have "//" before the protocol 
name. Change it to a single slash and that should work.

-- 
Best Regards,
Nikolay Kudryavtsev