vim.lsp.buf.definition() should work with vim-go's stack

[bitwombat]

What did you do?

Used a key mapped to vim.lsp.buf.definition()
Hit <C-t>

What did you expect to happen?

Expected the stack to be popped and me returned to the original file.

What happened instead?

I stayed in the definition file. Received message: vim-go: at bottom of the godef stack

I understand vim-go key maps <C-]> and <C-t> to GoDef and StackPop, but in order to work with multiple languages, I use other keys which are mapped to vim.lsp.* function calls. I was hoping that vim-go would somehow play nice with Neovim's LSP client and stack pushing/popping would work.

Configuration (MUST fill this out):

vim-go version:

master/a494378

vimrc you used to reproduce:

vimrc

call plug#begin()

    Plug 'fatih/vim-go', { 'do': ':GoUpdateBinaries' }
    Plug 'neovim/nvim-lspconfig'

call plug#end()

lua << END_OF_LUA
vim.lsp.start(
    { name = 'gopls',
      cmd = {'gopls'},
      root_dir = vim.fs.dirname(vim.fs.find({'main.go'}, { upward = true })[1]),
    }
)
local lspconfig = require('lspconfig')
lspconfig.gopls.setup {}
END_OF_LUA

Vim version (first three lines from :version):

NVIM v0.9.0
Build type: RelWithDebInfo
LuaJIT 2.1.0-beta3

Go version (go version):

go version go1.20.2 linux/amd64

Go environment

go env Output:

GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/gbell/.cache/go-build"
GOENV="/home/gbell/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/gbell/.asdf/installs/golang/1.20.2/packages/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/gbell/.asdf/installs/golang/1.20.2/packages"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/gbell/.asdf/installs/golang/1.20.2/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/gbell/.asdf/installs/golang/1.20.2/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.20.2"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/data/info/programming/my_software/listen-later/go.mod"
GOWORK=""
CGO_CFLAGS="-O2 -g"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-O2 -g"
CGO_FFLAGS="-O2 -g"
CGO_LDFLAGS="-O2 -g"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build2223096910=/tmp/go-build -gno-record-gcc-switches"

gopls version

gopls version Output:

golang.org/x/tools/gopls v0.11.0
    golang.org/x/tools/[email protected] h1:/nvKHdTtePQmrv9XN3gIUN9MOdUrKzO/dcqgbG6x8EY=

vim-go configuration:

vim-go configuration

g:go_loaded_install = 1
g:go_jump_to_error = 1
g:go_loaded_gosnippets = 1

filetype detection configuration:

filetype detection

filetype detection:ON  plugin:ON  indent:ON

[bhcleek]

You're free to disable vim-go's definition related mappings that control the stack by leveraging g:go_def_mapping_enabled (see :help g:go_def_mapping_enabled), but I'm not aware of any way to cause another plugin's behavior to affect the stack that vim-go maintains.

You could also configure the mappings to do whatever you find preferable by using a after/ftplugin/go.vim file.

edit: typos

[bitwombat]

Thanks @bhcleek. That helps.

Why does vim-go maintain its own stack, rather than use vim's built-in tag stack?

Oh, and thanks for all the vim-go maintenance/dev work! 🦸=you. vim-go is such a useful plugin.

[bhcleek]

Vim-go maintains its own stack, because there didn't used to be an easy easy way to hook into Vim's tag stack. #667 has some relevant background.

Looking into this a bit more, it appears that Vim has added some functions that may make this easier to deal with now. I'll leave this open, because I may be able to leverage settagstack() now. vim/vim@f49cc60 was added in 2018. I'll see if I can do anything with that to avoid the need for a custom stack and custom mappings.

As a further breadcrumb for myself, see :help tagstack-examples.

[bhcleek]

@bitwombat can you give #3548 a try (being sure that g:go_def_mapping_enabled is either undefined or else set to 1!) and see if it resolves your request?

[bitwombat]

Beaut, works great!
Should the mapping for <C-]> also be released back to default? I'm thinking no, because even with the change, you aren't pushing/navigating based on tags, you're just using the tag stack.

[bhcleek]

I don't see any reason to avoid vim-go's mapping for <C-]> when g:go_def_mapping is enabled regardless of whether settagstack is available. Does that answer your question?

[bitwombat]

Yep. Thanks for the quick response. I'll look forward to the merge.