Different textmate scopes for members

[jnmcfly]

As a designer of a theme, that respects terraform syntax. It would be nice to have different colors for deeper nested object attributes/vars. Now it's only other.Member.

Maybe that's possible in @pjmiravallle and #547

[aeschright]

The documentation I'm looking at doesn't provide many details about how those variable scope naming conventions, so I'm interested in your feedback as a theme designer. Is there a specific textmate scope you would expect to see used for the additional variable members?

[jnmcfly]

I would like to have different scopes for each attribute separated by a dot, to give it different color highlighting. Like: [scope.terraform-provider][scope.terraform-resource][scope.terraform-name][scope.terraform-attribute]

[radeksimko]

This is a useful feedback and actually very timely.

I recently started working on traversal/address expression support on the language server side and I know that the LS will need to understand these address segments and assign some meanings to them, so it would make sense for us to expose these details via semantic tokens too.

I'm not sure I fully understand the example scopes you mentioned above, but we should be able to assign scopes such as:

• variable.resource.type
• variable.resource.refname
• variable.resource.attribute

for something like aws_instance.example.public_ip, or

• variable.datasource.root
• variable.datasource.type
• variable.datasource.refname
• variable.datasource.attribute

for something like data.aws_instances.example.public_ip.

I'm not sure yet how and whether we're going to expose the data types of attributes beyond just identifying map and array keys, such as owner in aws_instance.example.tags["owner"].

Would this be helpful to you?

[radeksimko]

Actually now that I'm looking deeper I'm not so sure about the level of detail we can expose given how traversals are represented within HCL itself: https://pkg.go.dev/github.com/hashicorp/hcl/v2#Traverser The main problem is that we only get code range for the whole traversal, not for individual steps, so we'd probably have to do some math, or modify HCL internals somehow.

We could probably assign some custom modifiers such as resource, datasource (to the whole traversal) etc., but even that will be a stretch at this point, given that currently we assume modifiers are generic and applicable to any HCL language (not just to Terraform).

That's not to say it's impossible, but I'm just not confident this would be implemented in the first stages of traversal/reference support in LS that I'm currently working on.