Location list not being parsed correctly if setting g:go_metalinter_command

[bitwombat]

What did you do?

I set g:go_metalinter_command to the same command I could see :GoMetalinter running when I had g:go_debug=['shell-commands'] set.

:let g:go_metalinter_command="/home/me/go/bin/golangci-lint run --show-stats=false --output.text.print-issued-lines=false --build-tags playground --path-mode abs --default=none --enable=govet --enable=revive --enable=errcheck /prj/listen-later/service"

And then I ran :GoMetalinter

What did you expect to happen?

I expected navigable quickfix output like this, which is what it does if I don't set go_metalinter_command:

service/update.go|30 col 9| Non-inherited new context, use function like `context.WithXXX` or `r.Context` instead (contextcheck)                                                                                    
service/update_test.go|67 col 8| Error return value is not checked (errcheck)

What happened instead?

I got un-parsed output in a non-navigable quickfix list:

|| /prj/listen-later/service/update.go:30:9: Non-inherited new context, use function like `context.WithXXX` or `r.Context` instead (contextcheck)                                     
|| /prj/listen-later/service/update_test.go:67:8: Error return value is not checked (errcheck)                   

Configuration (MUST fill this out):

vim-go version:

master/06ac993

vimrc you used to reproduce:

vimrc

let g:go_gopls_enabled = 1
let g:go_auto_type_info = 1

if !filereadable(vimplug_exists)
  if !executable(curl_exists)
    echoerr "You have to install curl or first install vim-plug yourself!"
    execute "q!"
  endif
  echo "Installing Vim-Plug..."
  echo ""
  silent exec "!"curl_exists" -fLo " . shellescape(vimplug_exists) . " --create-dirs https://raw.githubusercontent.com/junegunn/vim-plug/master/plug.vim"
  let g:not_finish_vimplug = "yes"

  autocmd VimEnter * PlugInstall
endif

" Required:
call plug#begin(expand('~/.vim/plugged'))

"*****************************************************************************
"" Plug install packages
"*****************************************************************************
Plug 'fatih/vim-go', {'do': ':GoInstallBinaries'}

" Initialize plugin system
call plug#end()

Vim version (first three lines from :version):

VIM - Vi IMproved 9.1 (2024 Jan 02, compiled Sep 05 2025 19:44:46)
Included patches: 1-16, 647, 678, 697
Modified by team+vim@tracker.debian.org

I've not included a the configurations below because I believe they are n/a and am trying to save the sanitizing effort. If they are of interest, my apologies, and I will provide them.

Go version (go version):

n/a

Go environment

go env Output:

n/a

gopls version

gopls version Output:

n/a

[bhcleek]

Because you set the linter command to a command that vim-go doesn't know for sure, vim-go doesn't know how to handle the output. This is one of the tradeoffs of specifying your own command. Vim-go could probably do a couple things to improve the situation, but I'm not sure any of them are worth pursuing.

The most viable alternative that I see is to make a small fix to how vim-go handles the 'errorformat' for custom tools and simply make sure that the user's 'errorformat' value is respected - that would put the control fully in the user's hands. However, this solution won't avoid the problem you saw until you set 'errorformat' correctly, and I suspect that the vast majority of vim-go users do not know how 'errorformat' works and those that do want to use a custom tool would be frustrated by having to parse Vim's dcoumentaiton forefm-entries.

Another alternative is to fully remove support for other tools - I just don't know if there's any compelling reason to keep this feature around.

A third alternative is for vim-go to look at the first segment g:go_metalinter_command and try harder to figure out if it's a known command. That may not make much sense to do, though - I've literally never heard a compelling case for wanting more control over the command line arguments for those tools. Additionally, this alternative doesn't solve for the general case where some unexpected metalinter is being used.

Yet another approach is to be clearer about the expected format of the output and ask users to ensure that their tool outputs in the expected format. That will surely lead to documentation headaches and silly conversations about how to wrap tools need to provide output in the expected format. Additionally, that could already be done by simply creating a script that's callable as the name of one of the existing supported tools (e.g. golangci-lint).

[bitwombat]

Thanks for the explanation!

Ah, with the one-liner (!) in #3729, any external linter can be used to populate the quickfix list. That seems like a good idea, since that's the standard way to use external tools with Vim.

I suspect that the vast majority of vim-go users do not know how 'errorformat' works

The help for g:go_metalinter_command could say "In order for the output of the metalinter to be processed correctly into a quickfix list, you'll need to provide your own errorformat", and then link to :help error-file-format

I've literally never heard a compelling case for wanting more control over the command line arguments for those tools

With the way vim-go calls golangci-lint by default, it reports only on the errors in the current folder. I like to run it with ./... to get the list of everything wrong in the project. I also usually like to use --fix.