Unexpected new buffer with default main.go content is opened when using :GoRun, if log message to stderr contains filename.

[sssmack]

What did you do? (required: The issue will be closed when not provided)

After :GoRun completes with the following file, vim will automatically open a new buffer that contains default main.go file and switch to that buffer.

The issue seems to be caused by the log messages going to stderr and the messages having a space and filename in the message. In other words, If the log flag that causes the filename to be included is not used, then the issue goes away.

Put the following into a file named main.go
------------snip--------
package main

import (
"log"
)

func main() {
log.SetFlags(log.Lshortfile | log.LstdFlags)
log.Println("foo")
}
---------------snip------------
start vim
run :GoRun

What did you expect to happen?

I expected to see the log messages in a separate vim screen (and did)

What happened instead?

I saw the log messages in the split screen and then unexpectedly a new buffer with a default main.go source code appeared and it was put into the current screen

Configuration (MUST fill this out):

NAME="Ubuntu"
VERSION="20.04.1 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
export PRETTY_NAME="Ubuntu 20.04.1 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal

vim-go version:

v1.24

vimrc you used to reproduce:

vimrc

filetype plugin indent on

Vim version (first three lines from :version):

NVIM v0.4.3 (but the issue also happens with VIM 8 )
Build type: Release
LuaJIT 2.1.0-beta3

Go version (go version):

go version go1.15.3 linux/amd64

Go environment

go env Output:

GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/james/.cache/go-build"
GOENV="/home/james/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE="gitlab.jc.net"
GOMODCACHE="/home/james/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/james/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="off"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build626747373=/tmp/go-build -gno-record-gcc-switches"

gopls version

gopls version Output:

golang.org/x/tools/gopls v0.5.2
    golang.org/x/tools/gopls@v0.5.2 h1:lyHTekqy0QhXzz5hDFnfMGHk0Qmuq+LWH5VN/o19YLk=

vim-go configuration:

vim-go configuration

g:go_jump_to_error = 1
g:go_fmt_command = 'goimports'
g:go_autodetect_gopath = 1
g:go_loaded_install = 1
g:go_highlight_generate_tags = 1
g:go_highlight_function_calls = 1
g:go_list_type = 'quickfix'
g:go_highlight_fields = 1
g:go_highlight_functions = 1
g:go_highlight_extra_types = 1
g:go_highlight_types = 1
g:go_loaded_gosnippets = 1

filetype detection configuration:

filetype detection

filetype detection:ON  plugin:ON  indent:ON

[bhcleek]

There isn't a good solution for this. I can make it so that the new buffer doesn't come up when the exit code of go run is zero, but when there's a non-zero exit code this would still happen, because vim-go needs to be able to parse the output of go run when there are build failures. Unfortunately, the output of go run is very similar to the output of the log output in your application.

This is a more generic problem than even that, though. Even if vim-go were to use a slightly modified error format so that the log statements your application is outputs would not be detected as go run errors, it would still be possible for an application to output logs that would be detected as errors no matter what we do.

Your best option is to us !go run :GoRun would otherwise see your program's output as errors.

golang/go#13440 is relevant to this problem, too.

[sssmack]

In any case, why would the :GoRun ever open a new editor buffer with the default main.go stub code? Assuming that the vim-go error "scraping" only reads from stderr, I may have the app log to stdout when it detects that it is running from avim environment else to stderr. .. I have yet to test this out.

…

-Jim

On Tue, Nov 10, 2020, 9:53 PM Billie Cleek ***@***.***> wrote: There isn't a good solution for this. I can make it so that the new buffer doesn't come up when the exit code of go run is zero, but when there's a non-zero exit code this would still happen, because vim-go needs to be able to parse the output of go run when there are build failures. Unfortunately, the output of go run is very similar to the output of the log output in your application. This is a more generic problem than even that, though. Even if vim-go were to use a slightly modified error format so that the log statements your application is outputs would not be detected as go run errors, it would still be possible for an application to output logs that would be detected as errors no matter what we do. Your best option is to us !go run :GoRun would otherwise see your program's output as errors. golang/go#13440 <golang/go#13440> is relevant to this problem, too. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3085 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACBPLA4N3LTDCMJSI7DD5YTSPIKFHANCNFSM4TQ5FU7Q> .

[sssmack]

There isn't a good solution for this. I can make it so that the new buffer doesn't come up when the exit code of go run is zero, but when there's a non-zero exit code this would still happen, because vim-go needs to be able to parse the output of go run when there are build failures. Unfortunately, the output of go run is very similar to the output of the log output in your application.

This is a more generic problem than even that, though. Even if vim-go were to use a slightly modified error format so that the log statements your application is outputs would not be detected as go run errors, it would still be possible for an application to output logs that would be detected as errors no matter what we do.

Your best option is to us !go run :GoRun would otherwise see your program's output as errors.

golang/go#13440 is relevant to this problem, too.

The Go log package has a feature for setting a prefix to the log message and so I set that to "# " since the errorformat skips lines that start with that. I used that as a hack to prevent the issue.
However the vim-go feature where :GoRun opens a new buffer with default "main.go" code after :GoRun has output that matches errorformat makes no sense because the same invoke of GoRun has just ran a go file that is not the default main.go.
The fix seems easy enough -- when I can devote time, I will propose a fix to vim-go.

[bhcleek]

However the vim-go feature where :GoRun opens a new buffer with default "main.go" code after :GoRun has output that matches errorformat makes no sense because the same invoke of GoRun has just ran a go file that is not the default main.go.
The fix seems easy enough -- when I can devote time, I will propose a fix to vim-go.

The name was not main.go. The name of the buffer was the time + main.go. e.g. 2020/11/11 14:37:45 main.go.