search

zealdocs / zeal

Offline documentation browser inspired by Dash
https://zealdocs.org
GNU General Public License v3.0
11.37k stars 778 forks source link

-verify <url> cli option #1045

Open RJVB opened 5 years ago

RJVB commented 5 years ago

I've been giving some more attention to my KF5 port of the old zealsearch KTextEditor plugin which I've made to work with KDevelop5 too. I've actually had some positive feedback from the KDE community, and generated some interest for Zeal.

The plugin is very simple: it launches Zeal with a dash: URL containing the selected text or the word under the cursor (the pattern is shown in the lookup context menu action). This could be streamlined a little if there were a fast way to check whether that pattern exists in the available docsets. I'm thinking of a commandline option where Zeal will not put up its full UI if not already running (or won't come to the foreground if already running) and will exit as quickly as possible with a non-zero exit code if the pattern cannot be found (if could still fork when not already running so that a subsequent lookup will be faster). Projects integrating Zeal can use that to determine if they should enable a "lookup in zeal" menu item.

Does that sound like something feasible and worth considering? I could have a go at this myself if it doesn't require too much of an overhaul.

trollixx commented 5 years ago

The master plan is separating UI from the rest of the code base. The headless service will be accessible via an API by the UI, and other plugins. Generally I don't like when apps use CLI as an API. CLIs are for humans.

Also keep in mind that search is a pretty heavy operation, it may be not wise running it just to decide whether to show a menu item or not.

RJVB commented 5 years ago

Generally I don't like when apps use CLI as an API. CLIs are for humans.

I don't disagree, but you use what you got, right?

Also keep in mind that search is a pretty heavy operation, it may be not wise running it just to decide whether to show a menu item or not.

Practice would show whether or not to do this but isn't part of the point of having a search index that it decreases the searching overhead?

One way searching could be sped up is when docsets have a registered set of mimetypes or document extensions associated with them. Would also help with the final result list in the UI. When I look up "string" or "file" in a Tcl document I'm generally not very interested in 99% of the results ;)