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
which can be enabled via prefillRequiredFields and corresponding setting in VS Code terraform.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:
All other properties (usually sortText, filterText, insertText and textEdit) must be provided in the textDocument/completion response and must not be changed during resolve.
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 on source 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
Implement code action which pre-fills missing required attributes
Implement code action which pre-fills all attributes
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:
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: