Load buffers with :GoDef relative to cwd

[arp242]

If I use gd on an identifier the filename for the new buffer is set to:

~/work/src/github.com/teamwork/desk/server/server.go

Instead of:

server/server.go

This makes it open the relative directory, making it behave as :e server/server.go.

I think this change should be safe and will work for everyone? I'm not 100% of
that, though. Perhaps we should add a setting?

[fatih]

Hi @Carpetsmoker

Sorry but I've didn't understand what this solves. I've tried your change and I was not able to see any difference. How can I see what's changing? :ls still shows the full path and I'm not sure how to check it out. I appreciate more information.

[arp242]

Curious; I'll check and provide some more info next week. Just arrived in Venice for a holiday :-)

[fatih]

@Carpetsmoker did you had a chance to look at this?

[arp242]

You can reproduce the problems with symlinks:

$ pwd
/home/martin/work/go/desk

$ realpath .
/home/martin/work/src/github.com/teamwork/desk

As you can see, ~/work/go/desk is a symlink to ~/work/src/github.com/teamwork/desk.

Vim resets the working directory to the "real" path when opening a file:

$ vim main.go
:pwd
/home/martin/work/src/github.com/teamwork/desk

:echo expand('%')
main.go

But when editing another file, it doesn't set the full path:

:e server/server.go
:echo expand('%')
server/server.go

Now back to main.go:

:e main.go

and I gd on an identifier to the server/server.go file:

:echo expand('%')
/home/martin/work/src/github.com/teamwork/desk/server/server.go

The full path is now expanded, as if I had typed :e /home/martin/work/src/github.com/teamwork/desk/server/server.go.

The expected behaviour – for me anyway – is to have it maintain a relative path, like :e does.

Hope this explains things :-) Sorry for the delay.