You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
However, be warned that we may want more than just pure documentation here. As much as possible, we try to generate our documentation from the gopls source. This prevents duplication, and helps ensure that documentation doesn't go stale. It also makes it easier to compile our documentation into JSON that can be read by editors. You can see examples of this in x/tools/gopls/doc/generate.go.
I haven't thought too much about code actions, but we should try to do something similar, basing our documentation off of x/tools/internal/lsp/source.DefaultOptions().SupportedCodeActions. One way to enforce that we have documentation would be to change the type of SupportedCodeActions. For example:
In the future we could also go further and try to refactor such that code actions are parameterized, similarly to inlay hints (see x/tools/internal/lsp/source.AllInlayHints), but I don't think it is wise to undertake that refactoring now.
CC @suzmue@jamalc who may have opinions, having just done this for inlay hints.
@jadekler sorry for missing your question. Code actions may return either workspace edits or commands, so there is a lot of overlap with the command documentation but they are distinct. I think the point of documenting code actions is that users can bind keys to specific code action workflows.
I recently refactored the code action code somewhat for performance reasons (https://go.dev/cl/511995), after which it is slightly easier to see which code action kinds are supported.
I don't think we need to block this issue on perfectly parameterizing the code action logic. If anyone wants to help out on this, I think it would be suitable to start out with manual documentation: