Error message interaction failing

[Omegaice]

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.

[joefitzgerald]

@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.

[Omegaice]

No, clicking on that line does nothing at the moment.

[joefitzgerald]

Can you please post a screenshot, as well as the output of Packages > Go Plus > Display Go Information?

[Omegaice]

GoPlus Information:

Error message (Clicking it does not move the cursor to the error line):

[joefitzgerald]

What is the absolute path of main.go in the example you posted?

[Omegaice]

It is /Users/Omegaice/Documents/Code/RafflecopterSpider/rafflecopter-spider/main.go

[joefitzgerald]

Can you try moving your whole RafflecopterSpider directory inside your GOPATH? I.e. /Users/Omegaice/Documents/Code/Go/src/RafflecopterSpider.

[joefitzgerald]

+1 for finishing the feature #15, I think.

[Omegaice]

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.

[joefitzgerald]

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:...

[joefitzgerald]

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.

[joefitzgerald]

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.

[joefitzgerald]

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.

[Omegaice]

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.

[joefitzgerald]

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.