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
Users can today complete a whole block in two steps.
In the first step they complete the block type
In the second step they complete the labels for the block
However, many users, especially those who don't know the Terraform language and conventions as well don't necessarily think "I need a resource/data source" at first. They think "I need an EC2 instance" or similar.
Expected User Experience
Users will be presented with "composed" items such as
resource "aws_instance"
data "aws_ami"
provider "aws"
in addition to the existing "plain" resource, data and provider, when they request completion outside of any block.
Additionally we would also pre-fill any required fields for the block, assuming #719 is already implemented by the time we get to this.
There we could modify the behaviour of CandidatesAtPos so that for positions where it would typically return top-level blocks, such as resource, data, or provider, it would additionally return "composed" items such as resource "aws_instance", data "aws_ami", provider "aws" etc.
It is likely we'd want this behaviour to be opt-in, at least initially.
It is likely that we won't need to modify the Terraform schema as the existing schema should allow us to make informed decisions about which blocks are eligible for this kind of "composing", specifically combination of IsDepKey && Completable in LabelSchema may be sufficient.
TBD: filtering and sorting of completion items
The text was updated successfully, but these errors were encountered:
One more idea which came up while working on hashicorp/hcl-lang#177 is that we could reduce the completion steps in cases where there is exactly one candidate - e.g. attribute accepts string typed references and there's exactly one string typed reference.
Semi-relatedly we also could avoid TriggerSuggest: true in cases where we know there are no candidates but one possible downside with this is that number of suitable candidates may change at any time between offering completion and submitting it - so probably better to avoid this for the false negatives.
Problem Statement
Users can today complete a whole block in two steps.
In the first step they complete the block type
In the second step they complete the labels for the block
However, many users, especially those who don't know the Terraform language and conventions as well don't necessarily think "I need a resource/data source" at first. They think "I need an EC2 instance" or similar.
Expected User Experience
Users will be presented with "composed" items such as
resource "aws_instance"
data "aws_ami"
provider "aws"
in addition to the existing "plain"
resource
,data
andprovider
, when they request completion outside of any block.Additionally we would also pre-fill any required fields for the block, assuming #719 is already implemented by the time we get to this.
Proposal
All of the work would likely take place on the language server side, more specifically within the https://github.com/hashicorp/hcl-lang library.
There we could modify the behaviour of
CandidatesAtPos
so that for positions where it would typically return top-level blocks, such asresource
,data
, orprovider
, it would additionally return "composed" items such asresource "aws_instance"
,data "aws_ami"
,provider "aws"
etc.It is likely we'd want this behaviour to be opt-in, at least initially.
It is likely that we won't need to modify the Terraform schema as the existing schema should allow us to make informed decisions about which blocks are eligible for this kind of "composing", specifically combination of
IsDepKey
&&Completable
inLabelSchema
may be sufficient.TBD: filtering and sorting of completion items
The text was updated successfully, but these errors were encountered: