Request: option to suppress delve debugging logs

[sbromberger]

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

:GoDebugStart on a Go file.

What did you expect to happen?

Debugging to start, with relevant output captured in the __GODEBUG_OUTPUT__ panel.

What happened instead?

Lots of logs prefixed by ERR, though debugging seems to be working well. Examples:

OUT: 13
ERR: 2019-03-28T11:34:28-07:00 debug layer=rpc (async 20) <- RPCServer.Command(api.DebuggerCommand{"name":"next","ReturnInfoLoadConfig":null})
ERR: 2019-03-28T11:34:28-07:00 debug layer=debugger nexting
ERR: 2019-03-28T11:34:28-07:00 debug layer=rpc (async 20) -> rpc2.CommandOut{"State":{"Running":false,"currentThread":{"id":2409128,"pc":17527814,"file":"/Users/seth/dev/go/src/github.com/sbromberger/vimtest/foo.go","line":19,"function":{"name":"main
ERR: 2019-03-28T11:34:28-07:00 debug layer=rpc <- RPCServer.Stacktrace(rpc2.StacktraceIn{"Id":1,"Depth":5,"Full":false,"Defers":false,"Cfg":null})
ERR: 2019-03-28T11:34:28-07:00 debug layer=rpc -> *rpc2.StacktraceOut{"Locations":[{"pc":17527814,"file":"/Users/seth/dev/go/src/github.com/sbromberger/vimtest/foo.go","line":19,"function":{"name":"main.main","value":17527232,"type":0,"goType":0,"opt
ERR: 2019-03-28T11:34:28-07:00 debug layer=rpc <- RPCServer.ListLocalVars(rpc2.ListLocalVarsIn{"Scope":{"GoroutineID":1,"Frame":0,"DeferredCall":0},"Cfg":{"FollowPointers":false,"MaxVariableRecurse":0,"MaxStringLen":20,"MaxArrayValues":20,"MaxStructFields":
ERR: 2019-03-28T11:34:28-07:00 debug layer=rpc -> *rpc2.ListLocalVarsOut{"Variables":[{"name":"y","addr":824634207960,"onlyAddr":false,"type":"int","realType":"int","flags":0,"kind":2,"value":"85","len":0,"cap":0,"children":[],"base":0,"unreadable":"","Loca
ERR: 2019-03-28T11:34:28-07:00 debug layer=rpc <- RPCServer.ListFunctionArgs(rpc2.ListFunctionArgsIn{"Scope":{"GoroutineID":1,"Frame":0,"DeferredCall":0},"Cfg":{"FollowPointers":false,"MaxVariableRecurse":0,"MaxStringLen":20,"MaxArrayValues":20,"MaxStructFi
ERR: 2019-03-28T11:34:28-07:00 debug layer=rpc -> *rpc2.ListFunctionArgsOut{"Args":[]} error: ""
ERR: 2019-03-28T11:34:31-07:00 debug layer=rpc (async 24) <- RPCServer.Command(api.DebuggerCommand{"name":"next","ReturnInfoLoadConfig":null})
ERR: 2019-03-28T11:34:31-07:00 debug layer=debugger nexting

I confirmed with a delve committer that these messages were not errors, but merely logs of interactions with the debugger. I would prefer not to see these, as it obscures other output.

Configuration (MUST fill this out):

• vim-go version: master as of 2019-03-28 12:10pm PT

• vimrc you used to reproduce (use a minimal vimrc with other plugins disabled; do not link to a 2,000 line vimrc):

call plug#begin('~/.vim/plugged')
Plug 'fatih/vim-go', { 'do': ':GoUpdateBinaries' }
call plug#end()

• Vim version (first three lines from :version):

VIM - Vi IMproved 8.1 (2018 May 18, compiled Mar 26 2019 01:54:18)
macOS version
Included patches: 1-1050

• Go version (go version):

go version go1.12.1 darwin/amd64

• Go environment (go env):

GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/seth/Library/Caches/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/seth/dev/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/Cellar/go/1.12.1/libexec"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.12.1/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
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 -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/2s/2yph0ncn3cd9myvzw2cn8l_w0000gn/T/go-build112698024=/tmp/go-build -gno-record-gcc-switches -fno-common"

[bhcleek]

They are not errors, they're just the diagnostics that delve sends on stderr , hence ERR. You're free to ignore them.

[bhcleek]

FWIW, you can also close the window if you'd like...

[sbromberger]

Is there a way to suppress them, though? That's the feature request that would be very helpful, since my program's stdout gets overwritten by these logs.