Closed ziulev closed 2 years ago
adding to that: I would welcome to do that for the already existing plugins. For example, a local directory structure in Application support or the like. Where one can copy and paste plugins – or remove already existing. I like this project very much but I would like to disable a few of the plugins, as I do not want to use some of them at all.
Thank you for your addition @relikd. I plan to implement it in the next release.
And regarding external plugins: Frankly, I doubt the implementation of it. I have some ideas to implement similar logic as language-servers. (for example typescript-language-server). Provide a bridge between plugins and spotter via bash commands. But there are some problems - how to call methods, assign unique identifiers?
I'm sure there is a better way, so far I don't know it. Continuing to researching. If anyone has any ideas, please let me know.
Thought of it myself a while. I think I would have gone a similar way like sublime text. Require developers to assign a unique identifier in a plugin description json or similar. With a well-defined API like "here is the input, give me your results" and a callback if the entry was selected. Preferably with pressed keys (eg. in Spotlight you can open Finder at the selected entry if you hold down the cmd key.
Other than that, I think I would have experimented with just calling scripts (bash, python, etc.). E.g., require the script file to be callable via CLI (myplugin -s TEXT
) which will return a json (for example) and report back if you selected something (mylugin -r PARAMS
). Would be nice if the plugin could pass data to Spotter that is later returned to the plugin. E.g. if one would implement a file search I would not want the plugin to search twice (once to display the result and a second time when a result is selected). Instead the plugin could pass the file reference and Spotter will pass this reference along with a selection command back to the plugin.
Support for external plugins