Share gopls instance with ycm

[JackDrogon]

I use ycm for go. And I also use vim-go. But each of them create a gopls instance. Is there any way to share gopls instance with ycm.

[bhcleek]

I don't know of anyway to do this.

[hmgle]

I found a trick to share the gopls server with all other editor instances, not only with ycm.

1. Rename the gopls, in order not to start gopls by vim-go or ycm, vim-lsp...

mv $GOPATH/bin/gopls{,-server}
mv your_YouCompleteMe_DIR/third_party/ycmd/third_party/go/src/golang.org/x/tools/cmd/gopls/gopls{,.bak}

2. Create the gopls script:

echo '#!/bin/sh

nc localhost 9877 # or socat - tcp:localhost:9877' > $GOPATH/bin/gopls
cp $GOPATH/bin/gopls your_YouCompleteMe_DIR/third_party/ycmd/third_party/go/src/golang.org/x/tools/cmd/gopls/gopls
chmod a+x $GOPATH/bin/gopls
chmod a+x your_YouCompleteMe_DIR/third_party/ycmd/third_party/go/src/golang.org/x/tools/cmd/gopls/gopls

3. We start the gopls in TCP server mode, this command can be registered to system services to run on system startup:

gopls-server serve -listen "localhost:9877" -logfile /tmp/gopls_$RANDOM.log

4. Then open the go files with vim, no matter how many vim instances are started, you can see just one gopls-server is running, all clients are communicating with the gopls-server using the TCP protocol.

There is a problem with ycm: it will send the exit notification to the gopls-server when it is closed. I just comment the code related to this exit:

def Exit():
  # return BuildNotification( 'exit', None )
  pass

I hope they can provide a config to avoid exit the gopls-server.

[bhcleek]

@stamblerre can you weigh in regarding whether the technique that @hmgle suggests is supported by gopls and what the ramifications for adopting it may be?

[hmgle]

As @thomasfaingnaert mentioned prabirshrestha/vim-lsp#469 (comment), we can start the gopls server outside of Vim, and use ch_open instead of netcat or socat.

[bhcleek]

@hmgle there are more concerns here than simply whether or not the technique is theoretically possible. gopls serve is mostly intended for debugging right now, and I'm concerned that advising people to use it and multiplexing connections may be sending them down an unsupported path that will make it difficult for those of us that are editor maintainers and the gopls maintainers to analyze issues, and may expose users to unexpected and strange bugs.

Also, despite the comments on prabirshrestha/vim-lsp#469 (comment), dealing with stdio on Windows is handled by Vim pretty well.

I'd suggest waiting until you experience real problems with multiple gopls instances running before recommending hacks to avoid multiple instances.

[stamblerre]

I would not recommend doing this, as we do ultimately intend to support this in gopls directly (golang/go#34111). It probably won't happen very soon, as it's not a high priority, but I would not endorse hacks to get around this, for the reasons that @ianthehat describes in his comments on that issue.