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.amrom.workers.dev%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.amrom.workers.dev%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.amrom.workers.dev%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.amrom.workers.dev%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.