Zeal on linux is ignoring the first parameter (the query)

it seems on linux the following will omit the first parameter when passed to zeal

xdg-open "dash-plugin:query=shared_ptr&keys=cpp,net,boost,qt,cvcpp,cocos2dx,c,manpages"

while the following works just fine

xdg-open "dash-plugin://query=shared_ptr&keys=cpp,net,boost,qt,cvcpp,cocos2dx,c,manpages"

According to https://kapeli.com/dash_plugins the dash-plugin format is dash-plugin://keys={keywords}&query={query} which matches my expectation for uri.

It seems in 137f5b30a96d89e58316fcbdbf8bce4a21726b9d you explicitly avoided this, but I'm not sure what the rational behind this was. Rolling back this change seems to fix the issue for me.

Zeal version 0.3.1 atom-dash 1.7.1

The change was made because of KDE being very strict about the URL format, and in this case // should not be there. Zeal should parse that just fine, I'll check that.

I have tried it, and both xdg-open commands work just fine, with or without double slashes.

It might be a problem specific to your setup. What are your system and desktop environment?

Interesting! I'm just running a fairly default fedora 25 installation (Gnome 3). Not quite sure what else is releavant. xdg-open version 1.1.1+, zeal 0.3.1.

I can look a little farther into tracking down the source of the problem, I just thought it was an "easy fix" but clearly something more interesting is going on here. Thanks :).

Try running Zeal with the whole URI:

zeal "dash-plugin:query=shared_ptr&keys=cpp,net,boost,qt,cvcpp,cocos2dx,c,manpages"

That works as expected.

So, the problem is somewhere between xdg-open and Zeal. Fedora uses .desktop file provided by us, so it should work just fine.

Also my xdg-open is slightly older, but I don't think that's the reason.

% xdg-open --version 
xdg-open 1.1.0 rc3

I am open to ideas :)

I think I've tracked it down. Created a quick .desktop file to print out what it's receiving from xdg-open

└> xdg-open "dash-plugin:query=shared_ptr&keys=cpp,net,boost,qt,cvcpp,cocos2dx,c,manpages"
dash-plugin:///query=shared_ptr&keys=cpp,net,boost,qt,cvcpp,cocos2dx,c,manpages
└> xdg-open "dash-plugin://query=shared_ptr&keys=cpp,net,boost,qt,cvcpp,cocos2dx,c,manpages"
dash-plugin://query=shared_ptr&keys=cpp,net,boost,qt,cvcpp,cocos2dx,c,manpages/

Looks like xdg-open is introducing a third slash. When executing zeal with the third slash it doesn't correctly parse. Going to have to think about how to fix it but at least we have a cause :)

Looks like it's a problem with gio. xdg-open has a bunch of logic to decide who he asks to open his uri for him. If I put a dummy gio in my path before the system gio it falls back on gvfs-open and it works as expected.

For the time being maybe we can launch zeal directly (maybe hidden by a package configuration parameter if that's undesirable behavior).

Fedora pulls in many of post 1.1.1 xdg-utils changes, that my Arch version doesn't have. GIO support is one of them. I guess it makes sense to file a bug report with xdg-utils and Fedora. Since that code hasn't been officially released yet, not too many users are affected.

I think that's reasonable. A bug filed with gio is probably reasonable as well since it's the one actually mangling the URIs. I can hold local modifications of my package until that's resolved. I don't think there's anything to be done on your end as it's not your bug :). Thanks for the time!

No problem, thanks for debugging this.

When you file bug reports, please post links here, just for the reference.

@sphaerophoria did you end up opening a bug about this?

There is https://bugzilla.redhat.com/show_bug.cgi?id=1426299, but I am not certain that this is the same issue.

Just to mention that I have the same problem on my setup (Archlinux, xdg-open v1.1.2). Adding the // solves the problem for me too

We removed // due to KDE problem, and xdg-open is supposed to handle such URLs properly. I wonder if skype: protocol works with the new xdg-utils...

I've seen that but since it causes issues in other environment maybe an option on Linux to choose to have // or not might be beneficial. You can leave it disabled by default to keep the current behavior and allow users to enable it if they face this problem.

EDIT: I tried a call to xdg-open "mailto:me" and the to field in filled with ///me, looks like what has been seen in a previous comment