plugin system for editors

[yourilima]

Are there bindings that could be used to develop plugins for editors? just like dash has quite a few? most interresting for me would be for sublime text

[jkozera]

Not at the moment, sorry. I'm not familiar with Dash's bindings. I might look into them in future when I get time, but at the moment I'm too busy.

In the meantime, code contributions are welcome, so if anyone feels like implementing bindings, please go ahead. :)

[Kapeli]

Dash uses a dash:// URL scheme to integrate with other apps. Basically, opening a dash://{query} URL just opens Dash and sets the search field to the query. I'm not sure how this would work in Linux/Windows, but I'm sure they must allow some form of custom URLs.

You could support the dash:// URL scheme yourself and all of the Dash plugins should work. Note: the Xcode and Alfred plugins use a different integration method and hence will not work, but these 2 are OS X-only so it shouldn't matter.

Or, you could support a zeal:// URL scheme and modifying the Dash plugins to use that should be trivial.

[yourilima]

awesome. I'd have to get some time to get into the code for me to contribute. I'll see what I can do

[christoffer]

I was looking into this today, and came up with this info which might be helpful.

The preferred solution would be what @Kapeli suggested (handling the dash:// protocol). However it seems like it might be a bit more involved due to the plugin maintainers (fair) assumption that they are running on OSX. Mostly this means that they assume open is available (emacs plugin and sublime plugin does this). However the vim plugin is one example where the assumption is a bit stronger (it uses apple script to check for Dash being installed, link).

So my first thought to simply either extend the scripts to check for xdg-open (or equivalent on Windows if there is something) on other platforms wouldn't be enough. Also it seems like xdg-open (which is the by far most commonly available mime-handler as I understand it) has the nasty effect of going to the browser for all urls. This means it leaves a little tab in firefox or chrome before going on to open the associated app.

So my current suggestion would unfortunately be to go the long way. Require the Zeal executable to be on the PATH and fork the relevant plugins to add checks for it. Hopefully the checks are unintrusive enough for the original plugin managers to consider merging it in.

I wouldn't mind spending some time on this if you'd like @yourilima.

Some relevant links:

XDG Open
Registering URL Handlers in Linux

[jkozera]

Hmm, I was looking into what other people do with their Zeal forks, and I think you might find this patch adding dbus messaging support by @gilligan useful: gilligan@6100778

It doesn't solve your issues with xdg-open, but implements a way to call Zeal search from the outside. I guess you might prefer to use the existing QLocalSocket for simplicity, so I'll leave it up to you to decide which way to do it.

[christoffer]

Ah interesting, thanks for the link. DBus is definitely interesting (I read up a bit on it). A after a quick look around it seems like quite a big hurdle for plugin developers to implement DBus bindings. Most editors seem to lack it and requires (large-ish) third party libraries to be able to use it. It seems as much less of a hurdle, from the plugin developer standpoint, to execute an external program.

Since it's -- at least in my limited experience with API design -- you absolutely need to make it as easy as possible to implement it, or the uptake will suffer a lot. For this particular case, I think the easiest we can make it is requiring the plugin to know how to get at the zeal executable.

Does that make sense?

I'm thinking that the actual implementation would then be exec: zeal --query 'ruby|Hash' and the executable delivers the search query through the local host that is already there. Adding this to existing plugins should be fairly minimal.

[jkozera]

Yes, I agree running the zeal executable is the simplest API. I was thinking you could use DBus to talk to the main instance of Zeal from the executed-by-plugin instance, but it's probably simpler to use a simple socket, which is already implemented.

[gilligan]

I had absolutely zero prior experience with dbus programming and hadn't done any C++ programming in a couple of years either and it took me only a couple of hours so I'd say it's rather easy to do.

On the client/editor side it's even easier because you only need to invoke some dbus command line tool like dbus-send or similar. Personally i'd much prefer that to a custom socket communication protocol.

[christoffer]

Oh that's interesting! Didn't realize there was dbus executables that you could use. I assume they are installed by default on most distros / windows?

I'll definitely look into it some more then. Wouldn't mind at all doing something with DBus, it looks really nice.

[christoffer]

I looked into this a bit more and I think that I'm still going to implement it using arguments for the binary (and the internal implementation using the existing localhost connection).

It does indeed look really smooth to get this on linux by just using the mentioned dbus-send executable, however you can't do it on Windows as far as I can tell. To me that means that it would be a marginally better experience to develop plugins on one platform and a vastly worse hinder other platforms (Windows and OSX) since the executables are not readily available on those platforms.

The custom socked protocol would only be used internally to pass the query from the newly started (via zeal --query 'stuff') to the currently running instance. It would of course be possible to write something that uses that protocol, but that's another story. The suggested interface would be to execute zeal.

[expez]

Any updates on creating an API? I would love to call Zeal from emacs.

[jkozera]

Since ea5e141 (by @christoffer) you can simply run zeal --query 'my query' to pass a query to Zeal.

[jinzhu]

@expez I built a package for emacs, check it out. https://github.com/jinzhu/zeal-at-point

[expez]

Looks great, @jinzhu!

[a-sk]

For vim we can use https://github.com/Keithbsmiley/investigate.vim
with something like this in vimrc:
let g:investigate_command_for_python = '/usr/bin/zeal --query ^s'

[k3rni]

a completely minimal vim example, using gz (mnemonic: Go to Zeal, and apparently unused in Vim):

:nnoremap gz :!zeal --query "<cword>"&<CR><CR>

<cword> is the word under cursor, so it won't work by highlighting in visual mode. And the ampersand and double CR is to make Vim return to editing, and not stick in the command line.

[jkozera]

@jinzhu @a-sk @k3rni Thanks! I've added your solutions to http://zealdocs.org/usage.html with 79abb31 (also link to a package for Sublime Text).

[KabbAmine]

I've done a more complete vim script for Zeal (But still simple) https://github.com/KabbAmine/zeavim.vim

[joaomsa]

@christoffer as far as I know xdg-open works perfectly, you just have to register the mime type with xdg-mime. For dash:// it would be xdg-mime default zeal.desktop x-scheme-handler/dash

[trollixx]

Support for dash:// and dash-plugin:// on Freedesktop systems has landed in the master branch.

[trollixx]

Windows support has been added as well.

Now all Dash plugins should work with Zeal as well.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for a related request.