Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

x/tools/gopls: format of workspace/didChangeConfiguration parameters? #41767

Open
ilohmar opened this issue Oct 3, 2020 · 3 comments
Open

x/tools/gopls: format of workspace/didChangeConfiguration parameters? #41767

ilohmar opened this issue Oct 3, 2020 · 3 comments

Comments

@ilohmar
Copy link

@ilohmar ilohmar commented Oct 3, 2020

What version of Go are you using (go version)?

$ go version
go version go1.15.2 linux/amd64

Does this issue reproduce with the latest release?

Yes.

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/il/.cache/go-build"
GOENV="/home/il/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/il/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/il/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/opt/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/opt/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build462115165=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Send a workspace/didChangeConfiguration request, with any of various parameters: usePlaceholders, gofumpt, completeUnimported etc.

I am working on the integration and configuration from Emacs' eglot.el, and my problem is that most configuration is described in terms of VS Code --- so it is specific to one editor, something that, ironically, LSP was supposed to get rid of... ;)

I am looking for a description of the actual settings parameter for the request. Here is an example for a specific parameter:

[client-notification] Sat Oct  3 14:23:15 2020:
(:jsonrpc "2.0" :method "workspace/didChangeConfiguration" :params
          (:settings
           (:gopls
            (:gofumpt t))))

The format looks alien, but the settings parameter would transmit as

{
  "gopls": {
    "gofumpt": true
  }
}

which looks fine to me. The request does not trigger any error.

What did you expect to see?

A change in behavior.

What did you see instead?

No change in behavior -- neither any formatting according to the stricter gofumpt rules, nor a behavior in completion items (cannot disable completion of unimported symbols) etc.

I tried to rule out all Emacs/eglot-specific error sources as best I could. I also tried to check the wider-spread alternative lsp-mode handling as well as the gopls source itself, but could not find what I was looking for --- pointers appreciated.

gopls works fine with eglot out of the box, it is just the config changes that elude me. Thanks for any help!

@gopherbot gopherbot added this to the Unreleased milestone Oct 3, 2020
@stamblerre
Copy link
Contributor

@stamblerre stamblerre commented Oct 4, 2020

The didChangeConfiguration message should contain just the { "gofumpt": true } part, not the "gopls" part--I think that should fix the issue.

@stamblerre stamblerre removed this from the Unreleased milestone Oct 8, 2020
@ilohmar
Copy link
Author

@ilohmar ilohmar commented Oct 10, 2020

Thanks for your reply. I will try to make good use of this info for the Emacs/eglot integration. It seems that eglot is not flexible enough with the server configurations right now, but I will need to block some time to investigate that.

It seems to me that the workspace/didChangeConfiguration call triggers gopls to immediately ask the client for workspace/configuration. I don't quite understand why the LSP offers both call directions, and why gopls asks for the config --- what is really effective (for gopls) in the end, the didChangeConfiguration parameter settings, or the client reply to configuration? Or do they serve different purposes?

@stamblerre
Copy link
Contributor

@stamblerre stamblerre commented Oct 12, 2020

Currently, gopls doesn't actually read the content in the didChangeConfiguration, but rather just re-requests the workspace/configuration. We should probably change it to read the altered settings, but it should still work with the client either way.

@stamblerre stamblerre changed the title x/tools/gopls: Correct format of workspace/didChangeConfiguration parameters? x/tools/gopls: format of workspace/didChangeConfiguration parameters? Oct 12, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.