I was looking for autocomplete support that would be aware of all relevant Go packages (in GOPATH, in project and vendor'd); I played a bit with ctags but couldn't get anything out of it.
So here I am proposing to add autocomplete support through [gocode](https://github.com/nsf/gocode) which is pretty much what other editors use (although I find gocode buggy itself, but that is another topic).
## General idea of this PR * we would need an option to use gocode, either enabled or disabled by default; possibly gocode port too in case you're running multiple gocode daemons * once this feature is enabled, the `autocomplete_scope` radically changes behavior and instead of using `tm_workspace_find_scope_members` it would rely on a gocode CLI call for each autocomplete resolution request (yes, pricey, but useful) * the gocode CLI call receives the current buffer text via stdin and the results are parsed into `TMTag` structures * once tags are generated the autocomplete feature is pretty much unchanged (I am thinking of adding something for calltips, but not sure yet)
By the way, nice work with the block folding feature, I just noticed by compiling master.
## Feedback request Please notice this is a few ours work (kind of a POC), but I would like to have early feedback.
## Known issues of this PR * the tag creation should be improved and possibly moved to tagmanager (please advise on that) * the feature should be configurable and better packaged * not much used to C/GTK, so I don't even know how many leaks I am introducing here (possibly need to check with proper debug options or valgrind) * will adjust to proper coding style (yes I noticed the style you are using)
It works already (in this shaky version), see screenshot: 
You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/1457
-- Commit Summary --
* Preliminary work to add gocode support for autocomplete
-- File Changes --
M src/editor.c (242)
-- Patch Links --
https://github.com/geany/geany/pull/1457.patch https://github.com/geany/geany/pull/1457.diff
Good to see it work, but coding large amounts of filetype specific functionality into Geany core is not the way to go.
Instead the code in core should query a plugin that plugin uses gocode to answer the question. Then another plugin could support [Language Server Protocol](https://github.com/Microsoft/language-server-protocol) and another could use [libclang](http://clang.llvm.org/docs/Tooling.html#libclang).
When the plugin is loaded it should register to be called instead of tagmangler for autocomplete. Being able to register for other functions can then be added as separate PRs, eg formatting support, highlighting support (Scintilla willing), syntax error display etc etc
So the first thing is to specify the design of the interface to the plugin, and KISS.
@elextr thanks for your feedback. I see what you mean, I mentioned it in OP. I see the purpose of "adding support for external autocomplete plugin" as a completely separate project (much broader scope).
Ideally Go language support would be added as a plugin, but right now we have no such primitives to hook up plugins for autocompletion.
The "language support plugins" API needs to be flexible enough that more than one language can have a plugin, and each plugin can provide more than just the autocomplete service. The last is essential, its not sensible to run a language server for autocomplete, and another for formatting, and another for errors etc.
No single language (gocode or clang which appears elsewhere) should be implemented in its own way, Geany should have only one way of activating and communicating with language support plugins. The API needs to be DESIGNED first before anybody jumps in and implements stuff.
It also should be designed such that the whole shebang doesn't need to be implemented in Geany core at once, only your autocomplete is needed initially, but there is a design that can be expanded by anyone providing other services.
So as to not hijack this PR have opened #1458 for the general discussion.
@elextr no need to use capitals ("DESIGNED"), I know precisely what you are talking about (and frankly was surprised when I did not find "hooks" for autocomplete plugins already there). Well done with #1458, obviously I would not start such a discussion being so new about geany internals.
I think experiments like mine here in this PR (and similar), and also looking at the work done in other editors can help at designing the API.
I consider this "on hold" until the API is there, but I will develop it meanwhile for myself. Feel free to close it if there are no "on hold" PRs in this project.
@elextr no need to use capitals ("DESIGNED")
Apologies if unneeded, simply a reaction to bad experiences in the past.
I would not start such a discussion being so new about geany internals.
But as an interested party you should contribute because without the design may go nowhere, or head in a direction you don't like.
I consider this "on hold" until the API is there, but I will develop it meanwhile for myself. Feel free to close it if there are no "on hold" PRs in this project.
Appropriate label applied.
@elextr no worries, here, have a beer :beer: (or any other drink of choice if you don't like that), will try to stick around and contribute (incrementally). I will participate on #1458 for the plugin system design discussion
github-comments@lists.geany.org