broken when using xdg-open

[malb]

Hi there,

I had to change the URI to var uri = 'org-protocol:///';(note the three /) in order to make the extension work on Linux where it calls xdg-open. This seems to be a known problem, cf. https://github.com/alphapapa/org-protocol-capture-html#chrome

[sprig]

I had it working fine on linux. What is your setup?

[malb]

Debian GNU/Linux testing + Chrome.

[sprig]

@malb this is not enough information unfortunately.

What version of chrome? What desktop environment (or window manager)? What version?

[malb]

Chrome: Version 53.0.2785.143 built on Debian stretch/sid, running on Debian stretch/sid (64-bit)
DE: KDE/Plasma 5

[sprig]

How did you register org-protocol?

[malb]

I did:

$ cat .local/share/applications/org-protocol.desktop
[Desktop Entry]
Name=org-protocol
Exec=emacsclient "%u"
Type=Application
Terminal=False
Categories=System;
MimeType=x-scheme-handler/org-protocol;

I also tried without the quotes.

[sprig]

Could you temporarily change the line emacsclient "%u" to echo "%u" > ~/org-protocol.log and try capturing a few urls, then report contents of ~/org-protocol.log

Also, to confirm - is xdg-utils version 1.1.1-1 installed?

[malb]

I get:

$ cat ~/.local/share/applications/org-protocol.desktop
[Desktop Entry]
Name=org-protocol
Exec=echo "%u" >> ~/org-protocol.log
Type=Application
Terminal=False
Categories=System;
MimeType=x-scheme-handler/org-protocol;

$ cat ~/org-protocol.log
org-protocol:///capture:/p/https%3A%2F%2Fgithub.com%2Fsprig%2Forg-capture-extension%2Fissues%2F16%23issuecomment-256572280/broken when using xdg-open · Issue %2316 · sprig%2Forg-capture-extension/Could you temporarily change the line emacsclient %22%25u%22 to echo %22%25u%22 %3E ~%2Forg-protocol.log and try capturing a few urls%2C then report contents of ~%2Forg-protocol.log%0A%0AAlso%2C to confirm - is xdg-utils version 1.1.1-1 installed%3F
org-protocol:///capture:/p/https%3A%2F%2Fgithub.com%2Fsprig%2Forg-capture-extension%2Fissues%2F16%23issuecomment-256572280/broken when using xdg-open · Issue %2316 · sprig%2Forg-capture-extension/Could you temporarily change the line emacsclient %22%25u%22 to echo %22%25u%22 %3E ~%2Forg-protocol.log and try capturing a few urls%2C then report contents of ~%2Forg-protocol.log%0A%0AAlso%2C to confirm - is xdg-utils version 1.1.1-1 installed%3F
org-protocol:///capture:/L/https%3A%2F%2Fgithub.com%2Fsprig%2Forg-capture-extension%2Fissues%2F16%23issuecomment-256572280/broken when using xdg-open · Issue %2316 · sprig%2Forg-capture-extension

$ xdg-open --version
xdg-open 1.1.0 rc3

[sprig]

So, it appears that xdg-open is not swallowing the third '/'. When you use two slashes rather than three, does the extension not work everywhere or urls?

What are your emacs and org versions?

What are your capture templates?

[malb]

You're right. Repeating the experiment without my patch, I get:

$ cat org-protocol.log
org-protocol://capture/L/https%3A%2F%2Fgithub.com%2Fsprig%2Forg-capture-extension%2Fissues%2F16%23issuecomment-256651835/broken when using xdg-open · Issue %2316 · sprig%2Forg-capture-extension

It seem the problem isn't the //. Instead, note what there's no : after capture. So the problem seems to appear before emacs/org-mode is involved.

[sprig]

What exactly is your patch? I'm looking at the code and there is a colon after 'capture'.

Please right click a page which you want to capture, and press 'inspect'. Then, click on the capture button. There should appear a log line in the console with the message:

Capturing the following URI with org-protocol: .....

Please paste it.

[sprig]

Furthermore, I find it highly doubtful that the extension itself behaves differently under different OSs, and right now, on an OSX machine, I see that capture: is called. Let's try a different direction:

Please open up a shell and type:

org-protocol://capture:/L/foo/bar/baz/

and then paste the contents of the org-protocol.log

[sprig]

@malb I am happy to help you debug this, but the extension works fine on my linux machines so this is probably a problem with your specific setup. Furthermore, there is no evidence that your proposed patch won't cause degradation to other users.

[ExpHP]

Update: This is outdated. Turns out gio also shares the same "bug"!

---

I too am witnessing the second colon getting eaten.

tl;dr To the best I can surmise, the culprit is actually KDE.

NOT this extension;
NOT xdg-open.

---

Here's what I can see. Rather than debugging on emacs directly, here's a script that just prints its arguments.

argdebug

#!/bin/sh
for x in "$@"; do
        echo >&2 "'$x'"
done

~/.local/share/applications/emacs-capture.desktop

#!/usr/bin/env xdg-open
[Desktop Entry]
Name=Emacs Client
Exec=argdebug "%u"
Icon=emacs-icon
Type=Application
Terminal=false
MimeType=x-scheme-handler/org-protocol;

---

a direct call, of course, works fine...

$ argdebug "org-protocol://capture://L/aa/bb/cc"
'org-protocol://capture://L/aa/bb/cc'

xdg-open eats a colon...

$ xdg-open "org-protocol://capture://L/aa/bb/cc"
kf5.kio.core: Refilling KProtocolInfoFactory cache in the hope to find "org-protocol"
kf5.kio.core: Refilling KProtocolInfoFactory cache in the hope to find "org-protocol"
kf5.kio.core: Refilling KProtocolInfoFactory cache in the hope to find "org-protocol"
kf5.kio.core: "preferred service for x-scheme-handler/org-protocol" "emacs-capture"
'org-protocol://capture//L/aa/bb/cc'

but there's more to the story than just that. If I trace xdg-open using bash -x, I find that it very quickly delegates its job to another program:

$ kde-open5 "org-protocol://capture://L/aa/bb/cc"
kf5.kio.core: Refilling KProtocolInfoFactory cache in the hope to find "org-protocol"
kf5.kio.core: Refilling KProtocolInfoFactory cache in the hope to find "org-protocol"
kf5.kio.core: Refilling KProtocolInfoFactory cache in the hope to find "org-protocol"
kf5.kio.core: "preferred service for x-scheme-handler/org-protocol" "emacs-capture"
'org-protocol://capture//L/aa/bb/cc'

kde-open5 is eating the colon!

What is kde-open5? As far as I can tell, it's part of a CLI front end to various features of kio, which appears to be KDE's own magical url-handling system that tries to abstract file operations over "file://", "http://", "ssh://", zip files, radio transmissions from mars, and etc., etc.,

I tried looking further into it, but kde has a large and heavily factored C++ codebase that would take a while to digest.

---

aside: It's also very picky about what colons it eats. It's actually quite amusing. I have no cohesive explanation that can describe all of its output.

$ kde-open5 "org-protocol://capture://:L:/:a:a:/:b:b:/:c:c:"
'org-protocol://capture//:L:/:a:a:/:b:b:/:c:c:'
$ kde-open5 "org-protocol://capture//:L:/:a:a:/:b:b:/:c:c:"
'org-protocol://capture//:L:/:a:a:/:b:b:/:c:c:'
$ kde-open5 "org-protocol://:cap:ture://:L:/:a:a:/:b:b:/:c:c:"
(opens web browser to 'http://org-protocol//:cap:ture://:L:/:a:a:/:b:b:/:c:c:')
$ kde-open5 "org-protocol://capture://L://aa://bb://cc:"
'org-protocol://capture//L://aa://bb://cc:'
$ kde-open5 "org-protocol:///capture://L/aa/bb/cc"
'org-protocol:///capture://L/aa/bb/cc'

(the last example shows why #17 works as a workaround for KDE users; the extra slash somehow protects the colon)

---

$ uname -r
4.10.13-1-ARCH
$ xdg-open --version
xdg-open 1.1.2
$ kde-open5 --version
kioclient 5.9.5

[ExpHP]

Here is a (more) legitimate workaround:

Wrap emacsclient with a script that adjusts its arguments.

_emacs-capture

#!/bin/sh

# HACK: workaround for a kde-open bug (feature?) that might have
#       eaten a colon from our argument, om nom nom
argv=()
for arg in "$@"; do
    re='s_^org-protocol:/+capture:?/+_org-protocol://capture://_'
    argv+=("$(echo -n "$arg" | sed -Ez "$re")")
done

# Note: feel free to add any other arguments you want,
#  e.g. emacsclient --alternate-editor= -c "${argv[@]}"
emacsclient "${argv[@]}"

$HOME/.local/share/applications/emacs-capture.desktop

#!/usr/bin/env xdg-open
[Desktop Entry]
Name=Emacs Client
Exec=_emacs-capture "%u"
Icon=emacs-icon
Type=Application
Terminal=false
MimeType=x-scheme-handler/org-protocol;

(and don't forget to sudo update-desktop-database)

[sprig]

Awesome! Thanks for the detailed explanation and workaround, @ExpHP. I will add it to the readme.

[alphapapa]

Thanks to @ExpHP for that detailed analysis! I had no idea KDE was involved; I'm still on KDE 4, so I guess it does the same thing.

FYI, with the Org 9 org-protocol URL syntax, I think this shouldn't be an issue, as the colon is not necessary, e.g.:

javascript:location.href = 'org-protocol://capture-html?template=w&url='...

[ExpHP]

FYI, with the Org 9 org-protocol URL syntax, I think this shouldn't be an issue, as the colon is not necessary

Thank goodness! Though I suppose the problem now shifts to plugins like this that might need to support multiple versions.

I notice that on issue #30 where this issue was recently referenced, there's a report of the colon problem occurring on a non-KDE system, so it looks like this rabbit hole goes even deeper yet!

[alphapapa]

Yeah, sometimes the efforts to abstract differences create the need for more abstraction downstream. D: