Fixed bug when the file from goToDefinition is not in subdirectory

[akriegman]

the definition feature didn't work when the file returned by the server wasn't in the working directory, as is often the case with dependencies. This commit fixes this bug.

[akriegman]

If I'm not mistaken, that line was in there so that the name of the file wouldn't appear too long in the status bar / tab bar. One thing we could do is test whether the file path starts with the cwd and only truncate it then. The other thing we could do is set the name of the buffer separately from the path, and truncate the name however we want.

[AndCake]

@akriegman : yes correct. What about if the path is calculated as a relative path from where the cwd is? That should keep it not much longer than it is right now without loosing the ability to open stuff outside the cwd.

[akriegman]

That's not a bad option. I like the idea of truncating the name if it's too long, since for example with cargo my dependencies are all in a folder whose name is a long github url. So we could do something like (in pseudocode):

bp.path = filename -- absolute path
bp.name = filename.relative_to(cwd)
if #bp.name > 30 {
    bp.name = ".." .. bp.name.truncate_right(30)
}

or, if there isn't some easily accessible function for calculating relative paths, we can do:

bp.path = filename
bp.name = if filename.starts_with(cwd) {
    filename.strip_prefix(cwd)
} else if #filename > 30 {
    ".." .. filename.truncate_right(30)
} else {
    filename
} -- optionally also try to replace home folder with ~

[AndCake]

I like the second solution! That would make it easy enough to implement and at the same time look nice. However, if the truncate_right is applied, I would suggest to use three periods (so "..." instead of "..") to indicate that there is something before it. This should make it easier to identify that it is not the relative path but an ellipsis of a path.