dougm / go-projectile Goto Github PK

could you please create a tag to use this package using melpa stable [1].
Thanks

[1] : http://stable.melpa.org/

Hi, I am total emacs newbie, I've started with spacemacs and have no clue how to enable this package in it.

Would anyone help?

golang/tools@f941d54

The autoload in go-projectile-tools-add-path needs to be updated. Or maybe now that go-rename is on melpa you could add that package as a dependency instead of setting up load-path and autoload yourself.

I don't have a detailed report about this, but with the go-projectile package enabled, and active buffer was from a big project with thousands of files, most of Emacs lagged, as in bringing up a list of buffers via ido-switch-buffer would take about 2-4 seconds compared to being instant when active buffer was from a smaller project.

The slow-down effected everything from projectile-find-file to C-x k (ido-kill-buffer).

Don't know if it helps much, but my emacs config is available here: https://github.com/jimeh/.emacs.d

If there's anything else I can provide, just ask, takes seconds to install go-projectile again to get the behavior back :)

I'm trying to improve my emacs go editing experience and I've hit a bit of a snag. I like this package, but when it goes to install tools, one of those tools is gocode. I see that it installs it from a fork of the original, but that fork is not maintained any longer (github.com/mdempsky/gocode). It doesn't work at all with modules, which is the recommended method in lieu of GOPATH. There's another fork that supports modules, https://github.com/stamblerre/gocode. Unfortunately, it is also unmaintained. It recommends using gopls, which is what I'm using now and it works great. There are two places that I can see that use this tool.

• go-eldoc uses gocode extensively. See emacsorphanage/go-eldoc#51 for an issue on that repo that's pretty old and hasn't been responded to by someone who can commit to that repo. In fact there are two PRs just to update the link in the README, so I think this is probably not going to get fixed.
• go-projectile installs gocode, although I'm not sure exactly why other than for the benefit of go-eldoc (I didn't look very thoroughly). What are your thoughts on this?

Here is the output in *Messages*:

Go tool gocode: go get github.com/nsf/gocode
Go tool golint: go get github.com/golang/lint/golint
if: package golang.org/x/tools/go/gcimporter: unrecognized import path "golang.org/x/tools/go/gcimporter"
package golang.org/x/tools/go/types: unrecognized import path "golang.org/x/tools/go/types"

nsf/gocode is not being maintained, and a fork of the project has been made. The list of tools should be updated to reflect this (i.e. update this line to github.com/mdempsky/gocode).

oracle.el used to define its own minor mode, but now it just modifies go-mode-map when it is loaded. This causes errors in the go-projectile go-mode-hook.

golang/tools@68b5f75

It would nice to be able to use go-projectfile with something like gom (https://github.com/mattn/gom).

Given that go get is deprecated, we should change this line to use go install instead:

Which broke my EXWM!

I think projectile-go-project-p is a reasonable replacement.

About half of my projects don't use a global GOPATH, but use GOPATH=pwd to contain everything in one directory.
go-projectile-set-gopath works OK for that purpose initially, but when switching from a buffer PROJ-ROOT1 (which has a main.go) to another buffer PROJ-ROOT2/main.go go-projectile-derive-gopath seems to fail.

The problem is that "rel" correctly ends up being "main.go", but since a main.go is also to be found in PROJ-ROOT1 (locate-file rel (split-string path path-separator t)) evaluated to "t" which causes GOPATH to be the old PROJ-ROOT1