I'm working on a code-completion plugin for the Go (golang) programming language. The real "brains" of the plugin come from a command-line utility called "gocode" (https://github.com/nsf/gocode). You invoke that executable with a filename and a character offset position, and gocode returns a list of autocomplete suggestions based on a full analysis of the source code file... rather than simply by matching against a fixed list of static keywords.
Gocode is written in Go, which unfortunately supports only static compilation at this time. In other words, I can't bundle gocode directly into my plugin DLL. Gocode has to ship as a separate ".exe" file, to be called by plugin as an external process.
In my local testing, I have simply copied "gocode.exe" to NPP's "plugins" directory. My plugin code finds it it at (NPPM_GETNPPDIRECTORY + "\plugins\gocode.exe"), and is successfully invoking the external process and capturing its output.
However, before I proceed much further, I wanted to validate that I'm using an acceptable approach here. This is my first NPP plugin, so I'm not sure if the Plugin Manager allows you to ship a separate ".exe" file along with your ".dll". If so, then is the "plugins" directory alongside the DLL an acceptable location? I would like to make my plugin installation as standard and painless as possible, without making users install something separately and manually update their PATH, etc... are there any problems that I should aware of with my current approach?
The CCompletion plugin does pretty much exactly what you are doing for Go but does it for C/C++. It ships with ctags.exe, so yes, you can use exe files (don't know the best location to put it exactly). When you add your plugin to the plugin manager, you just tell it what files to copy where. It can copy any type of file so if you have html documentation or anything it can copy those too.
Also, you may want to use NPPM_GETPLUGINSCONFIGDIR instead of NPPM_GETNPPDIRECTORY because the plugin may install to the %APPDATA% directory for users without admin privileges.
Thanks for the information! This plugin is doing pretty much EXACTLY the approach I described, including bundling its external analyzer .exe in the "plugins" directory. However, if using the config directory and GETPLUGINSCONFIGDIR protects against an edge case that I probably wouldn't see in my own local testing, then I'll just do that instead.