Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

implement support for gopls #2146

Closed
bhcleek opened this issue Feb 16, 2019 · 12 comments
Closed

implement support for gopls #2146

bhcleek opened this issue Feb 16, 2019 · 12 comments
Assignees
Labels
Milestone

Comments

@bhcleek
Copy link
Collaborator

bhcleek commented Feb 16, 2019

implement support for gopls.

The initial implementation will provide the framework and foundational support in vim-go along with options to use gopls for g:go_def_mode. Follow on work will provide options to use gopls instead of guru, for g:go_info_mode, and other functions as gopls matures, with the ultimate goal of using gopls by default and eventually dropping all support for other tools whose functionality is going to be provided by gopls.

@bhcleek bhcleek added this to the vim-go 1.20 milestone Feb 16, 2019
@bhcleek bhcleek self-assigned this Feb 16, 2019
@bhcleek bhcleek added the wip label Feb 16, 2019
@fatih
Copy link
Owner

fatih commented Feb 18, 2019

I think this is a big milestone and going to shape the future of vim-go. What do you think of releasing updating the major version to v2.0 instead of v1.20? This would give us more flexibility (allow us to do some minimal breaking changes if needed) and also signal that vim-go that it's very different (or at least will be) going forward.

@bhcleek
Copy link
Collaborator Author

bhcleek commented Feb 18, 2019

I have a few thoughts about that.

First, I don't think that the introduction of support for gopls will justify going to 2.0. Perhaps after it's fully supported and support for all other tools is dropped, though. 2.0 would probably be:

  1. replace all tools possible with gopls
  2. drop support for Vim 7.4

However, I also think perhaps we should drop the 1.x vs 2.x paradigm entirely and just go to an ordinal number system for vim-go releases (e.g. v20, v21, v22, etc.), because we've have had to introduce some backward incompatibilities 🤔 , and using the M.m.P paradigm doesn't fit well with that fact.

@arp242
Copy link
Contributor

arp242 commented Mar 11, 2019

In my personal view, I'm not sure if implementing a LSP client in vim-go is wise. As I understand it an important advantage of LSP is that you can have one client interact with many different LSP servers. So I only need to write a LSP client once and then it works for Go, Python, TypeScript, Brainfuck, what have you.

There are already a number of good LSP clients for Vim today. I am currently using vim-lsc with bingo (gopls is in early stages of development and not usable yet). There are about 5 or 6 other production-ready LSP client plugins for Vim already (ALE would be another good choice).

This handles completion, go-to-definition, documentation, and a bunch of other stuff for which vim-go currently has a lot of code. Duplicating that effort in vim-go seems a bit redundant to me.

This is an important reason I started working on gopher.vim, which is also a testbed for some other ideas I have (some work well, others not so much ... yet).

My idea is that all "generic features" are off-loaded to generic plugins, so that the Go plugin can focus on just the Go-specific parts. Everyone's time is limited, and in my view limiting the scope of vim-go will mean there is more time available to actually make those parts work really well, and since the generic plugins have a larger audience base they should in principle have a better quality too (in my experience they do). I also think it provides a better overall Vim UX, since I only need to configure the generic plugin once, and then it will work well for many different filetypes (Rather than configuring a bunch of filetype-specific plugins). I think everyone wins with this approach, and thus far I have not seen any real drawbacks.

That's my 2 cents on the future of vim-go. I realize that this is a major paradigm shift, but like a lot of these kind of open source projects vim-go has a shortage of consistent long-term developers, and I think it would be good to spend the time that is available in the most efficient way possible.

@bhcleek
Copy link
Collaborator Author

bhcleek commented Mar 11, 2019

I understand that perspective.

The future of most of the tools vim-go depends on is uncertain, and some significant ones are not going to be updated to work with modules.

@cnbuff410
Copy link

When the PR 2163 is merged, does it mean we can start testing gopls with vim-go by assigning gopls to go_def_mode?

I can't wait to help test it. I am bothered so much by the messy status of the gocode that I pretty much abandoned vim-go temporarily and plan to come back after the support of the gopls.

@bhcleek
Copy link
Collaborator Author

bhcleek commented Mar 11, 2019

@cnbuff410 yes. As soon as it's merged I'm going to start on using gopls for code complection instead of gocode if gopls supports it already (I think it does, but I need to verify).

@vaijab
Copy link

vaijab commented Mar 13, 2019

As soon as it's merged I'm going to start on using gopls for code complection instead of gocode

How can I tell vim-go to use gopls for code completion?

@bhcleek
Copy link
Collaborator Author

bhcleek commented Mar 13, 2019

@vaijab it's not implemented yet.

@cnbuff410
Copy link

@bhcleek it does because my temporary replacement for vim-go is vscode + gopls. Looking forward!

@bhcleek
Copy link
Collaborator Author

bhcleek commented Mar 13, 2019

I didn't mean that it's not implemented in gopls; vim-go isn't using gopls for completion yet

@cnbuff410
Copy link

Oh right I got it, this is the answer to "if gopls supports it already"

@doronbehar
Copy link

Hello,

I'd like to use this closed issue in order to express my dearest support in @Carpetsmoker's opinion kindly expressed in his comment. I came by this issue after I've installed vim-go in branch master because I wanted to use debug features not available in v1.19 but I couldn't because of go#lsp functions' errors.

I think this is a good example for one of those very unfortunate and hard to witness cases where developers spend huge amounts of time and energy in implementing features which are provided by other projects. What makes this case so tragic is the fact that other developers have already thought about a solution to the same problem and came out with a solution a 100 times better. The sad fact is, that instead of cooperating, we are diverting.

We are Free software developers! We should be proud of our ability to drop our Ego aside and be happy to cooperate with each other! This is not only for the sake of saving your time - since we're all sailing this ship together you are wasting our time 😞.

To be more specific, I truly think. with all due respect, that if vim-go developers would dedicate more of their time for other features such as debugging, we - the users would benefit much more. For example, take remote debugging, it could have been absolutely awesome if it was possible to use this feature of dlv within Vim..

I've decided to use sebdah/vim-delve instead because it's scope is much smaller so I hope it will prove to be a better choice. Never the less, I'm saying this after I've taken a look at the code of both of these projects and the quality of vim-go seems to be much higher.

As for the "rival" language server client implementation, I think the one that should receive most of the attention from the community is coc.nvim. I think the main argument that makes it superior to any other vim LSP clients, is the fact that it supports extension features of VSCode. VSCode, (although a competing editor) has very mature support for many languages through the LSP. coc.nvim takes advantage of this fact and can share a lot of code with language specific support packages written initially for VSCode. IMHO, this makes coc.nvim a wonderful example of code reuse for the better good.

I'm writing this comment with the hope that the time I've put into writing it won't get lost like the time wasted on earth by multiple people implementing the same software. Please, remember that our cooperation with each other is what makes us a strong community.

Best regards,
A Free software developer.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
Projects
None yet
Development

No branches or pull requests

6 participants