Add scope detection based on VCS root about godoctor HOT 6 OPEN

@rdallman I've been thinking about this for a few weeks.

If there is a single main file/function, so we can set the scope to that. The Go repo, for example, has a cmd directory with several different commands, so there are actually several main programs in that repo.

If we can find the repo root, it wouldn't be hard to parse through the source files, find all of the files in the main package, and use those to set the scope. But we'd want to put this on a timeout -- don't search for more than, say, one second.

I haven't touched go/loader in a couple of years and forgot how it works (or doesn't). Do you have a sense of how well things work if we prime the loader with main functions vs. the repo root directory?

I think Rename is the only refactoring where scope really matters, since we look for references across multiple files. The other refactorings only modify a single file.

from godoctor.

This needs to be updated for modules and get rid of the GOPATH lingo, reminding myself to at least update the README instructions. now we can probably crawl up to the root module which is probably the same thing as the git root (just need to get rid of GOPATH to deduce)

from godoctor.

Or go.mod, whichever comes first?

from godoctor.

Even though git most certainly has won the VCS war, it feels wrong to me to have that be a requirement.

from godoctor.

Is it really too much to ask for people to run godoctor from the root of their workspace, and if they can't, then explicity provide it? That's what gopls does, as far as I can tell.

from godoctor.

yea this is more of a convenience, none of this is defaulted or required. we do require setting scope to run a refactoring, I'm mostly referring to updating https://github.com/godoctor/godoctor.vim/#setting-scope-to-git-root in my comment, which is flexible and still allows setting scope per refactoring - I agree yea, want to change lingo to look for go.mod rather than .git once this all works.

from godoctor.