-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use absolute paths for gometalinter, so that filenames resolve correctly #565
Conversation
It should be noted that |
Because gometalinter is run using ExecuteInDir, it outputs filenames relative to the source file being edited, which means that you cannot open them from quickfix. By using absolute paths, quickfix output is usable for jumps. This change also drops the superfluous go_metalinter_path.
3cd7866
to
65d6a4a
Compare
function! go#lint#Gometa(path_to_lint) abort | ||
function! go#lint#Gometa(...) abort | ||
if a:0 == 0 | ||
let goargs = expand('%:p:h') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You only pass the current file's path. Previously we were recursively looking for all files under the current buffer's directory (with ./...
). This means our :GoMetaLinter
functionality has changed. I've added g:go_metalinter_path
just for that, because for my case I want that it goes and lints all files.
I think I don't get an error because of this simple line in my vimrc:
autocmd BufEnter * silent! lcd %:p:h
So the fix here is to return absolute paths from gometalinter, not passing a folder just to make it return absolute paths.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
None of the other linters do recursive linting by default, why is GoMetaLinter a special case? There's no option to tell gometalinter to output full paths, so that's not a possible solution.
Passing a single file to gometalinter is not valid input, you must pass it a path (./...
is a path). You should still be able to call GoMetaLinter ./...
to get that behaviour, like some of the other linters.
I don't like the idea of forcing people to add stuff to their vimrc to get default behaviour working, and changing the working directory by default will produce unintended behaviour for users.
I understand not wishing to introduce breaking behaviour, but this is pretty fresh code, so there are probably not too many people affected, and at least this behaviour is consistent with the other linters.
PS: I fixed the errcheck output in gometalinter, so my comment above does not apply now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
None of the other linters do recursive linting by default, why is GoMetaLinter a special case? There's no option to tell gometalinter to output full paths, so that's not a possible solution.
We know the current directory via Vim. So we can prepend it to gometalinter output if we want, but I think this would make it more complex than simpler.
I understand not wishing to introduce breaking behaviour, but this is pretty fresh code, so there are probably not too many people affected, and at least this behaviour is consistent with the other linters.
Thinking now I think this is fair. Just let me use it a little bit and get a feeling for this.
Use absolute paths for gometalinter, so that filenames resolve correctly
Thanks @pdf for your contributions. |
@fatih most welcome, thanks for the prompt merges 😎 |
Because gometalinter is run using ExecuteInDir, it outputs filenames
relative to the source file being edited, which means that you cannot
open them from quickfix. By using absolute paths, quickfix output is
usable for jumps.
This change also drops the superfluous go_metalinter_path.