* org-protocol: deal with broken links on windows
@ 2017-08-23 20:02 Ingo Lohmar
2017-08-23 20:59 ` Nikolay Kudryavtsev
0 siblings, 1 reply; 4+ messages in thread
From: Ingo Lohmar @ 2017-08-23 20:02 UTC (permalink / raw)
To: emacs-orgmode
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
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: org-protocol: deal with broken links on windows
2017-08-23 20:02 org-protocol: deal with broken links on windows Ingo Lohmar
@ 2017-08-23 20:59 ` Nikolay Kudryavtsev
2017-08-24 17:00 ` Ingo Lohmar
0 siblings, 1 reply; 4+ messages in thread
From: Nikolay Kudryavtsev @ 2017-08-23 20:59 UTC (permalink / raw)
To: Ingo Lohmar, emacs-orgmode
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: org-protocol: deal with broken links on windows
2017-08-23 20:59 ` Nikolay Kudryavtsev
@ 2017-08-24 17:00 ` Ingo Lohmar
2017-08-25 19:38 ` Nikolay Kudryavtsev
0 siblings, 1 reply; 4+ messages in thread
From: Ingo Lohmar @ 2017-08-24 17:00 UTC (permalink / raw)
To: Nikolay Kudryavtsev, emacs-orgmode
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: org-protocol: deal with broken links on windows
2017-08-24 17:00 ` Ingo Lohmar
@ 2017-08-25 19:38 ` Nikolay Kudryavtsev
0 siblings, 0 replies; 4+ messages in thread
From: Nikolay Kudryavtsev @ 2017-08-25 19:38 UTC (permalink / raw)
To: Ingo Lohmar, emacs-orgmode
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2017-08-25 19:38 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-08-23 20:02 org-protocol: deal with broken links on windows Ingo Lohmar
2017-08-23 20:59 ` Nikolay Kudryavtsev
2017-08-24 17:00 ` Ingo Lohmar
2017-08-25 19:38 ` Nikolay Kudryavtsev
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).