-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Comments
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 |
I have a few thoughts about that. First, I don't think that the introduction of support for
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. |
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. |
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. |
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. |
@cnbuff410 yes. As soon as it's merged I'm going to start on using |
How can I tell vim-go to use |
@vaijab it's not implemented yet. |
@bhcleek it does because my temporary replacement for vim-go is vscode + gopls. Looking forward! |
I didn't mean that it's not implemented in gopls; vim-go isn't using gopls for completion yet |
Oh right I got it, this is the answer to "if gopls supports it already" |
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 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 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, |
implement support for
gopls
.The initial implementation will provide the framework and foundational support in vim-go along with options to use
gopls
forg:go_def_mode
. Follow on work will provide options to usegopls
instead ofguru
, forg:go_info_mode
, and other functions asgopls
matures, with the ultimate goal of usinggopls
by default and eventually dropping all support for other tools whose functionality is going to be provided bygopls
.The text was updated successfully, but these errors were encountered: