[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [O] org-protocol: deal with broken links on windows
From: |
Ingo Lohmar |
Subject: |
Re: [O] org-protocol: deal with broken links on windows |
Date: |
Thu, 24 Aug 2017 19:00:12 +0200 |
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