-
Notifications
You must be signed in to change notification settings - Fork 131
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
New Code Action: Fill block with optional+required attributes #1530
Comments
I'm working on a proposal regarding this issue, My idea was to fill the It looks that this is the intended solution provided by the lsp specification : https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#diagnostic This should not be CPU expensive as we are already publishing diagnostics. At me moment i'm filling variables with a |
Background
The following two PRs introduced support for pre-filling required attributes on completion:
which can be enabled via
prefillRequiredFields
and corresponding setting in VS Codeterraform.experimentalFeatures.prefillRequiredFields
. It looks like this in action:One of the problems with the above approach is that it's unclear what the user wants to do and what the completion should do when there are pre-existing attributes in the block body. There may be contexts where overwriting it is correct and other contexts where just adding missing attributes is correct. In the specific example above it would most likely make more sense to overwrite things because two different resources are unlikely to have common attributes. This may not be the case for all blocks (other than
resource
) though.Additionally, manipulating larger ranges of configuration during completion, especially if they require a lot of context is not common in LSP and similar problems in other servers are more frequently implemented as code actions. The LSP makes this difficult (intentionally or not) by mandating textEdits to be computed by the time the completion is requested and these cannot be resolved at a later stage via
completionItem/resolve
, as the spec says:This in turn can make such pre-filling mechanism very expensive in the sense that the server pre-computes text edits for potentially hundreds of options (and send all of them through RPC) when only one of them will be chosen and the rest is thrown away.
Another example where similar approach won't work for the reasons above is pre-filling of inputs in
module
block based onsource
because it would be prohibitevely expensive to download all metadata from the Registry API for all modules the user may wish to complete.Code actions could provide a different and more flexible way (from maintenance perspective) to solve this problem, even if that comes at the cost of different UX for the user.
Example of a similar action in gopls:
Proposal
Implementation Notes
The problem of "what to do with existing attributes" does not go away with code actions but it may be resolved a little more easily. We could offer different code actions and let the user choose what's appropriate (overwrite vs keep) and more importantly keeping code and calculating relatively costly text edit is more easily done at a later stage (compared to having to pre-compute everything early during completion).
The text was updated successfully, but these errors were encountered: