Skip to content
Paul Jolly edited this page May 8, 2019 · 21 revisions

What versions of Vim and Go are supported with govim?

The supported versions of Vim/GVim are most effectively summarised by the Travis build matrix:

https://github.com/myitcv/govim/blob/master/.travis.yml

Other combinations of Vim and Go may work.

For advice on building Vim from source, see here

Neovim is not supported; see #121 for discussion about potentially adding such support.

What do I need in my .vimrc?

Assuming you have the plugin installed correctly, a minimal .vimrc is shown in:

https://github.com/myitcv/govim/blob/master/cmd/govim/config/minimal.vimrc

Why have you created govim? What is/was wrong with vim-go?

This question and the one that follows are also covered in two talks I gave, YouTube recordings of which are available: London Gophers and Vim London.

Firstly, I would like to acknowledge all the work that @fatih, @bhcleek and contributors have put into vim-go. It's a phenomenal effort.

Secondly, some history. vim-go predates the channel support in Vim8. As such the way it emerged and evolved is very much a function of the world that existed back in 2014.

With that said, there is absolutely nothing wrong with vim-go! Indeed, vim-go is also using gopls for some commands/functionality.

github.com/myitcv/govim/cmd/govim is an experiment. It's an experiment that is looking to test the hypothesis that writing Vim plugins in Go (to support developing in Go):

  • will make for more readable/maintainable code
  • will enable more people to contribute
  • will allow common, intuitive, easy-to-understand building blocks to be created using Go primitives as opposed to VimScript primitives. i.e. we could provide a Go function/method that gets the current buffer contents rather than relying on knowledge that we need to evaluate the expression join(getline(0, "$"), "\n")
  • will, over time, allow a more usable API to establish itself
  • will allow for the use of existing developing tooling whilst working on github.com/myitcv/govim/cmd/govim (or any plugin that is build using github.com/myitcv/govim for that matter)

Why should I use govim over vim-go/vim-lsp/...? Why is govim not language agnostic?

Building on the answer above, govim was started as an experiment to test whether writing Vim8 plugins in Go would be easier, more fun etc. This answer adds my current (2019-04-18) personal (myitcv) thoughts. Note however that I'm very willing to be steered in a different direction on any of these points and more!

  • I focussed on gopls (and by extension, Go) in order to help quickly iterate on progress in gopls. Hence my goal was/is not "I don't want to support other languages/LSP implementations, ever"; rather, "I'm currently focussing on gopls"
  • there is therefore no particular reason to prefer it over vim-go, vim-lsp, coc.nvim or any of the other related projects. vim-go at least is far more mature in terms of code life. I've not tried vim-lsp with gopls
  • whilst there are (large) parts of govim that are language agnostic (because all its doing is talking LSP to gopls), having my stated goal be that govim is Go-specific (for now) feels like the most efficient way to iterate on the progress being made with gopls but also to flush out whether there are any Go-specific bits where the LSP spec itself needs to change. Making govim (or some derivative of it) language agnostic is being tracked in https://github.com/myitcv/govim/issues/194, but again, this not my primary goal right now

Is anyone actually using govim?

At least one person (me!) is using it 100% of the time, as a direct replacement for vim-go. Yes there are rough edges, but it's easy(ish) to iron out those rough edges, and the speed benefits of gopls make it vastly preferable.

You can’t perform that action at this time.