Vim-go: `let g:go_jump_to_error = 0` does not prevent new buffer from opening when using 3rd party testing packages

[sashaweiss]

Related to #367.

What did you do?

I ran :GoTest from a file containing a test that intentionally fails.

What did you expect to happen?

I expected the QuickFix buffer to open, showing me information about the error(s).

What happened instead?

The QuickFix buffer opened, along with a new file mypackage/assertions.go, which contained only the line package main. My cursor jumped into this new file.

The screenshot below shows my directory structure, a file containing some code, the file testing that code, and the mypackage/assertions.go buffer that opened. Note: the auto-opening buffer replaced my test file buffer, but for the screenshot I reopened the test file next to it.

Configuration:

• Vim version (first two lines from :version):
  VIM - Vi IMproved 8.0 (2016 Sep 12, compiled Dec 18 2017 10:09:08)
  macOS version
  Included patches: 1-1400
  Compiled by Homebrew

• Go version (go version):
  go version go1.9.2 darwin/amd64

• Go environment (go env):
  GOARCH="amd64"
  GOBIN=""
  GOEXE=""
  GOHOSTARCH="amd64"
  GOHOSTOS="darwin"
  GOOS="darwin"
  GOPATH="/Users/sasha/go"
  GORACE=""
  GOROOT="/usr/local/Cellar/go/1.9.2/libexec"
  GOTOOLDIR="/usr/local/Cellar/go/1.9.2/libexec/pkg/tool/darwin_amd64"
  GCCGO="gccgo"
  CC="clang"
  GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/kb/t4v3k6fx1hq6xlsd9mnyt2rc0000gn/T/go-build898171635=/tmp/go-build -gno-record-gcc-switches -fno-common"
  CXX="clang++"
  CGO_ENABLED="1"
  CGO_CFLAGS="-g -O2"
  CGO_CPPFLAGS=""
  CGO_CXXFLAGS="-g -O2"
  CGO_FFLAGS="-g -O2"
  CGO_LDFLAGS="-g -O2"
  PKG_CONFIG="pkg-config"

• vim-go version:
  v1.16

• vimrc you used to reproduce:
  If you'd like my full .vimrc, please let me know. Otherwise, these are the vim-go related options I have set.

call plug#begin('~/.vim/plugged')

Plug 'fatih/vim-go'

call plug#end()

" Vim-Go
let g:go_fmt_command = "goimports"
let g:go_jump_to_error = 0

Thanks in advance for your advice!

[bhcleek]

This is known behavior when using github.com/stretchr/testify, as you've already discovered: https://github.com/stretchr/testify/issues/83.

Now that we're using vim's error formats correctly, it may be easier to resolve than it was in the past. I'll give it a shot...

[sashaweiss]

Gotcha - sounds good, thanks! Please let me know if I can be helpful, or provide any more details.

[arp242]

The concept of test helpers that were introduced in Go 1.9 will probably mean that testify won't need to use hacks with terminal escape codes to overwrite the output.

Apparently the original testify isn't maintained, and doesn't support this (see https://github.com/stretchr/testify/pull/493). but the comments mention a fork which should fix this, if I read this diff correct.

[bhcleek]

I agree that with "testing.T".Helper, testify shouldn't need to play tricks anymore. FWIW, the original testify seems to be being maintained: https://github.com/stretchr/testify/commits/master. I'll put a small amount of time in to see if I can adjust the error formats to accommodate this, but I'm likely to close this issue as a won't fix, because Fatih has weighed in on this particular issue before.

[bhcleek]

RE: the status of stretchr/testify vs the fork
TL;DR: stretchr/testify was forked, the original maintainer, Ernesto Jimenez, showed back up and started adding new commits. Now there's an original and a fork 🤦‍♂️

https://github.com/test-go/testify/issues/1

[bhcleek]

@sashaweiss Can you try the latest master? I can replicate the issue you describe on v1.16, but it behavior slightly differently on master; it's not perfect, but I don't get a new buffer...

[sashaweiss]

Updated to master, and seeing the same behavior unfortunately...strange that you're seeing something different? Should I try cloning from your fork above?

[bhcleek]

I was able to duplicate what you're seeing; the reason I didn't before is that I'd constructed a test whose first error was not from testify.

The docs for g:go_jump_to_error explicitly say that it is only useful for vim-go's custom static mappings; g:go_jump_to_error does not apply to calling functions manually. You can call :GoTest! to avoid jumping to the first error, though.

[sashaweiss]

Awesome - :GoTest! works for me! Thanks so much!

Edit: In the end, I also forked vim-go and copied over the changes you made in that PR. Thanks @bhcleek for your help with this, and for figuring out those changes (even if they can't be included)!

[ernesto-jimenez]

@sashaweiss @bhcleek do you want to give https://github.com/stretchr/testify/pull/554 a try?

[sashaweiss]

Thanks for making those changes! Seems like it works for me.

Steps I took (just to make sure I did it right):

1. Go to stretchr/testify directory (under $GOPATH), pull, switch to the fix-vim-go branch, run go install
2. Change my .vimrc to use 'fatih/vim-go' instead of my fork, and re-install plugins
3. Open my previously-failing sample, and run :GoTest

One note: there's an extra space at the end of the first line (see screenshot). Not a huge deal, but highlights as red (since I have my vimrc set to highlight trailing spaces).

Thanks again for reviving this thread!

[sashaweiss]

Noticed the testify branch was merged - thanks @ernesto-jimenez!