Closed Omegaice closed 9 years ago
@Omegaice Are you able to click on the line / column / filename to go to the line? I think it may be a manifestation of the inclusion of the filename.
No, clicking on that line does nothing at the moment.
Can you please post a screenshot, as well as the output of Packages > Go Plus > Display Go Information
?
GoPlus Information:
Error message (Clicking it does not move the cursor to the error line):
What is the absolute path of main.go
in the example you posted?
It is /Users/Omegaice/Documents/Code/RafflecopterSpider/rafflecopter-spider/main.go
Can you try moving your whole RafflecopterSpider directory inside your GOPATH? I.e. /Users/Omegaice/Documents/Code/Go/src/RafflecopterSpider
.
+1 for finishing the feature #15, I think.
Ah, that is the issue. I go get my repositories and then symlink from the GOPATH directory to my code directory to work on them. If I open it from the GOPATH directory then it works.
I still feel that this could be a confusion to others and some caveat should be mentioned if you don't want to maintain this feature for symlinked code.
I'm trying to wrap my head around how I would support symlinked source. The reason the links are not working for you is that go build
outputs files with a path like ./main.go
.
In order to use these paths correctly with atom-message-panel
, I need an absolute path, and so I'm using the current directory of the package you save a file in as a prefix.
It feels brittle, but I'm not sure of a better way. It would be much nicer if go build
just output absolute paths :smile:...
I suppose I could begin to leverage the # path/to/your/package
hints from go build
to inform me of a relative path from one of your gopaths, which I can then iterate through to find the correct location.
It might make my regexp crazy, but crazy regexps are preferable to broken links.
After further deep inspection, Atom itself is expanding / resolving the symlink-ed path into its actual path, and I'm not sure how to undo that.
Given general consensus that the go tool does not support symlinks in a GOPATH (reference: https://groups.google.com/forum/#!topic/golang-nuts/f5ZYztyHK5I), I'm going to close this. #15 will warn when source is not within the GOPATH. #81, #74 and others will integrate with package management / go version management tools to ease your GOPATH management.
My understanding of the thread you posted was that they were doing it the other way around to how I am.
I have a standard GOPATH setup and then when I work on a repository I run "go get -d github.com/Omegaice/repository" and then create a symlink that links somewhere else to that repository, usually "ln -s $GOPATH/src/github.com/Omegaice/repository ~/Documents/Code/repository". From this linked directory I have no problems running go tools.
The thread you linked seems to be checking out the code, such as "git clone github.com/Omegaice/repository ~/Documents/Code/repository", and then symlinking that into the GOPATH by running "ln -s ~/Documents/Code/repository $GOPATH/src/github.com/Omegaice/repository" which seems to be causing the issues they are having.
I will look into the package management stuff to see if it fits with the way I want to work with golang.
Yes, I understand the logic you're applying but the net outcome is a symlink is still in use and due to the way that both Atom and go are built, there's no clear way forward here to reliably address the issue.
With the 2.0.2 release of go-plus and atom 0.120, I seem to be unable to click on any of the error messages to navigate to that line. I assume this is due to the changes made to close issue #44.