x/tools/gopls: reconsider and restructure setting parameter names #43101
Labels
FrozenDueToAge
gopls
Issues related to the Go language server, gopls.
Tools
This label describes issues relating to any tools in the x/tools repository.
Milestone
Comments
gopherbot
added
Tools
|
Change https://golang.org/cl/280192 mentions this issue: |
gopherbot
pushed a commit
to golang/tools
that referenced
this issue
Dec 30, 2020
This CL copies Heschi's structural changes to the options from CL 278433 and makes the necessary adjustments in the JSON and documentation generation. Nested settings are grouped together and the "status" of a given setting is also listed. Currently the only possible statuses are "experimental" and "debug", but I will add "advanced" in a follow-up (to indicate that a setting is only for advanced users). The options "set" function still expects flattened settings to avoid fundamentally changing people's current configurations, so VS Code Go will just have to make sure to flatten the settings before sending them to gopls (which should be easy enough). No names of any settings are changed (Heschi's earlier CL adjusted the experimental prefixes). As discussed offline, we've decided to prefix any setting that we expect to delete with "experimental", and so we'll leave existing setting names as they are. Updates golang/go#43101 Change-Id: I55cf7ef09ce7b5b1f8af06fcadb4ba2a44ec9b17 Reviewed-on: https://go-review.googlesource.com/c/tools/+/280192 Trust: Rebecca Stambler <rstambler@golang.org> Run-TryBot: Rebecca Stambler <rstambler@golang.org> gopls-CI: kokoro <noreply+kokoro@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Suzy Mueller <suzmue@golang.org>
|
Change https://golang.org/cl/280706 mentions this issue: |
gopherbot
pushed a commit
to golang/tools
that referenced
this issue
Jan 11, 2021
This CL copies Heschi's structural changes to the options from CL 278433 and makes the necessary adjustments in the JSON and documentation generation. Nested settings are grouped together and the "status" of a given setting is also listed. Currently the only possible statuses are "experimental" and "debug", but I will add "advanced" in a follow-up (to indicate that a setting is only for advanced users). The options "set" function still expects flattened settings to avoid fundamentally changing people's current configurations, so VS Code Go will just have to make sure to flatten the settings before sending them to gopls (which should be easy enough). No names of any settings are changed (Heschi's earlier CL adjusted the experimental prefixes). As discussed offline, we've decided to prefix any setting that we expect to delete with "experimental", and so we'll leave existing setting names as they are. Updates golang/go#43101 Change-Id: I55cf7ef09ce7b5b1f8af06fcadb4ba2a44ec9b17 Reviewed-on: https://go-review.googlesource.com/c/tools/+/280192 Trust: Rebecca Stambler <rstambler@golang.org> Run-TryBot: Rebecca Stambler <rstambler@golang.org> gopls-CI: kokoro <noreply+kokoro@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Suzy Mueller <suzmue@golang.org>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
There are many settings parameters that can be used to tune gopls behavior. The defaults were carefully chosen so most users don't need to configure them.
But when they do need customization, it should be easy to find the relevant settings.
Detailed documentation for individual setting helps, but I think it's better if
Some of currently available setting names are not very descriptive. (e.g.
local,matcher).FYI VSCode uses setting names (
configuration key) to namespace and group the settings. These name structure helps the plugin developer to grep/watch a part of configuration more efficiently. VSCode uses the name-based grouping to order and build graphical setting page UI. https://code.visualstudio.com/api/references/contribution-points#Configuration-schemaI originally attempted to map some of
goplssettings to VSCode-friendly setting names (that I chose based on the settings' role). For example, I was thinking patterns like<feature>.<behavior>when possible. (note: some settings are not cleanly mapped to one feature)But I think it's more desirable if all
gopls-based editors share the similar setting structures.I was also considering extending the
api-jsonoutput to include the group info as a field, and utilize the group info to auto-construct VS Code setting names. But for the reasons I mentioned above, I think it's better if the names carry sufficient info.The text was updated successfully, but these errors were encountered: