Support symbol renaming

[dsvensson]

Currently go-rename exists (MELPA), but is excruciatingly slow on even small code-bases. It would be really nice to have rename-support via go-langserver.

[keegancsmith]

This has been debated a few times in go tools issues. The problem is go guru/rename/mvpkg/etc have a concept of scope which very often defaults to your whole GOPATH. So go rename is slow because it is inspecting your whole GOPATH.

However, earlier this year there was mention of the go team improving this golang/go#10917 (comment)

But I think it is worth implementing this ourselves in go-langserver since we have the additional concept of a workspace so we can limit the rename work to just the current workspace. We do the same for find references, which is why find references is likely faster in go-langserver than the usual vscode-go shelling out to guru.

I'll happily accept patches around this since I won't have time to work on this soon.

[dsvensson]

At least in my environment, all application git-repos are GOPATH roots, so I clone example project foo.git to directory foo, and will then have foo/.git, foo/src/foo/main.go, foo/src/vendor/bar etc. go-projectile detects this and configures GOPATH accordingly and lets guru and all other tools play nice in emacs. I haven't used go-langserver yet, found it just an hour ago and I'm excited to try it out. How does it deal with GOPATH, from what I can tell, emacs doesn't send GOPATH to it at least. Should probably just play around with it instead of asking silly questions here :)

[keegancsmith]

aah, and its still slow? Then I'm not sure if we could make it faster. Although in theory it should be as fast as find references which we have made faster than go guru.

[Dbz]

I am just commenting to say I would also love to have go-langserver support symbol renaming 👍 !

[muni-corn]

Can this issue be marked as closed as of #337 ?