Option to auto-open location list if tests fail

[lorin]

If I run :GoTest, and there are test failures, to see them I need to open the location list (:lopen). I would love if the location list opened automatically if any tests failed. An option to enable this would be great.

[fatih]

Hi @lorin It opens automatically. Are you sure it doesn't ?

[lorin]

I did some digging to track this down. The problem seems to only manifest on neovim (not officially supported, I know...), and only when syntastic is loaded.

Here's a minimal .nvimrc file that reproduces the issue on my machine:

call plug#begin('~/.vim/plugged')
" plugins
Plug 'fatih/vim-go'
Plug 'scrooloose/syntastic'
call plug#end()

(I'm using vim-plug as my plugin manager).

[fatih]

I'm also using neovim and I think this is due syntastic (which I don't use btw). Closing this as this is not a vim-go issue. Thanks!

[lcd047]

I'm also using neovim and I think this is due syntastic

Nope, the problem is that both vim-go and syntastic are trying to manage the same loclist. As I pointed out elsewhere, this is not going to work, and the solution is for the OP to configure vim-go to use quickfix lists instead of loclists.

(which I don't use btw)

Which is great: you can blame everything on syntastic, and since I'm not using vim-go, I can blame it back on vim-go. A convenient perfect circle. :)

[fatih]

@lcd047 I'm not trying to blame or start a tension. Please talk for yourself. Here is a gif that shows how vim-go behaves:

And here is the code: https://github.com/fatih/vim-go/blob/master/autoload/go/cmd.vim#L63-L69 I even have an explicit settings just for jumping to the first error, called go_jump_to_error.

As you see it jumps to the first error. So vim-go works out of the box. Also we have extensive detailed settings and you can change the type via let g:go_list_type = "quickfix" easily as well.

How is that, vim-go is the one that is broken? Every time there is a problem with vim-go, it's always due syntastic. Heck I even have a dedicated section just for it: https://github.com/fatih/vim-go#using-with-syntastic

The first problem syntastic causes is that it builds on save. Which is an overkill for almost all projects. Because of these bad defaults, people complaint that this is an issue of vim-go, which again is not. And over and over I'm trying to explain people that this is not due vim-go.

So please don't try to make myself the bad guy here. I'm always trying to find the middle ground. Thanks

[lcd047]

I'm not trying to blame or start a tension.

Then please stop assigning blame without doing proper research, thank you.

Also we have extensive detailed settings and you can change the type via let g:go_list_type = "quickfix" easily as well.

Then perhaps the answer to the OP's question should have been to set g:go_list_type to quickfix, rather than hand waving at syntastic?

How is that, vim-go is the one that is broken?

Neither vim-go nor syntastic are broken. They just can't hope to control quickfix windows at the same time. This is the root cause of the problem, and the fix is to configure them to use different kinds of quickfix lists. I added a note to syntastic's manual to that effect.

Every time there is a problem with vim-go, it's always due syntastic.

Really? 814 issues and counting, every single one related to syntastic? That's nothing short of remarkable. :)

Heck I even have a dedicated section just for it: https://github.com/fatih/vim-go#using-with-syntastic

syntastic also has a note about vim-go. I suppose you only get to hear from people that don't care to read either though.

The first problem syntastic causes is that it builds on save.

Could be. However, this has nothing to do with the issue reported by OP.

Because of these bad defaults, people complaint that this is an issue of vim-go, which again is not. And over and over I'm trying to explain people that this is not due vim-go.

syntastic defaults go back to the beginning of the project, and apply to all filetypes, not just go. Perhaps make the note about syntastic more prominent? Do you have any suggestion for better handling of this (unrelated) issue?

[fatih]

Then please stop assigning blame without doing proper research, thank you.

I'm not blaming. I'm saying it's due syntastic, which is true ;)

Really? 814 issues and counting, every single one related to syntastic? That's nothing short of remarkable. :)

It's because it's the only and most used Go plugin. We have tons of features, with those we have issues, feedbacks and co. I think it shows the quality of the project, if you could interpret it that way you would understand it.

Could be. However, this has nothing to do with the issue reported by OP.

Well I've just noted my frustration with syntastic. Because you started saying that I'm blaming. I'm saying again, I'm not, I'm just explaining that syntastic causes these problems, and build on save is amongst one of them.

syntastic defaults go back to the beginning of the project, and apply to all filetypes, not just go. Perhaps make the note about syntastic more prominent? Do you have any suggestion for better handling of this (unrelated) issue?

It's pity that you can't change something because it's that way from the beginning. Imho it might be a good choice for pre 1.4.x but the compile time got worser after that. The go team is now working on a fix, though for large projects, build on save is still overkill and should be IMHO not the default.

I've added already something into readme. Seems like you also added a notice in your doc. The problem though is, people rarely read these. That's why, by default it should be sane out of the box. I suggest you to change that default.

Thanks

[fatih]

@lcd047 also I'm more than happy to solve problems. If there is anything we can do make the situation better let me know. We had a massive refactoring the last months to support custom list (quickfix vs location list), just so we can prevent issues like this. If you think there are still improvements to co exists together, happy to hear them.

[lcd047]

I'm not blaming. I'm saying it's due syntastic, which is true ;)

On second thought, there is something I can do to solve this for good: drop all support for go from syntastic. There doesn't seem to be anything syntastic can do about Go files that vim-go can't do better, and go itself doesn't fit too well with syntastic's idea of a checker. So this shouldn't be a huge loss for anybody. Good enough for you? Any other opinions?

[fatih]

@lcd047 that would sadden a lot of people. People still use it. I think we just need to be more aware of the certain cases, slow save, not jumping to first error and then warn people about it.

[gonzaloserrano]

Hi guys! First let you know that i love vim-go and syntastic! <3

I use syntastic with go because even it lags a bit on my company's projects (maybe in bigger projects is worse, i don't know) when saving i like to have direct feedback on what's the build error. In 1.7 it's gonna be at least twice as faster we know that already.

Then i wanted to report a possible improvement for the build time, not sure about it bu here it goes: based on this https://peter.bourgon.org/go-best-practices-2016/#build-and-deploy, looks like go install faster than go build in > 1 iteration because of compile caching. I've changed my syntastic config to do that and i think it's indeed faster. The changed line is here https://github.com/scrooloose/syntastic/blob/master/syntax_checkers/go/go.vim#L57

Hope it helps and thanks again.

[lcd047]

that would sadden a lot of people. People still use it.

I genuinely believe most people who use both syntastic and vim-go do that mainly because they are using a canned Vim environment like spf13 which came pre-packaged with syntastic. Anyway, I posted an informal request for comments on syntastic's tracker. I can make a similar post here, if that's fine with you.

[jefferai]

I apologize for commenting on a closed issue, but as a casual user that is not using a canned environment but has used vim-go and syntastic together for their various strengths, what is the best way forward here for someone that really likes having errors displayed for me on save?

[lorin]

@jefferai Adding this to your vimrc file will do the trick:

let g:go_list_type = "quickfix"

This is documented in the README.

[jefferai]

@lorin it didn't work for me. I didn't know if that's because it's old information or just...didn't work.

[jefferai]

I figured that it was just "old information" which is why I posted here.