zed/extensions/terraform/languages/terraform-vars/injections.scm

; https://github.com/nvim-treesitter/nvim-treesitter/blob/ce4adf11cfe36fc5b0e5bcdce0c7c6e8fbc9798a/queries/hcl/injections.scm

(heredoc_template
  (template_literal) @content
  (heredoc_identifier) @language
  (#downcase! @language))

; https://github.com/nvim-treesitter/nvim-treesitter/blob/ce4adf11cfe36fc5b0e5bcdce0c7c6e8fbc9798a/queries/terraform/injections.scm
; inherits: hcl
Support Terraform Variable Definitions as separate language (#7524) With https://github.com/zed-industries/zed/pull/6882 basic syntax highlighting support for Terraform has arrived in Zed. To fully support all features of the language server (when it lands), it's necessary to handle `.tfvars` slightly differently. TL;DR: [terraform-ls](https://github.com/hashicorp/terraform-ls) expects `terraform` as language id for `.tf` files and `terraform-vars` as language id for `.tfvars` files because the allowed configuration inside the files is different. Duplicating the Terraform language configuration was the only way I could see to achieve this. --- In the [LSP](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocumentItem), text documents have a language identifier to identify a document on the server side to avoid reinterpreting the file extension. The Terraform language server currently uses two different language identifiers: `terraform` - for `.tf` files `terraform-vars` - for `.tfvars` files Both file types contain HCL and can be highlighted using the same grammar and tree-sitter configuration files. The difference in the file content is that `.tfvars` files only allow top-level attributes and no blocks. [_So you could argue that `.tfvars` can use a stripped down version of the grammar_]. To set the right context (which affects completion, hover, validation...) for each file, we need to send a different language id. The only way I could see to achieve this with the current architecture was to copy the Terraform language configuration with a different `name` and different `path_suffixes`. Everything else is the same. A Terraform LSP adapter implementation would then map the language configurations to their specific language ids: ```rust fn language_ids(&self) -> HashMap<String, String> { HashMap::from_iter([ ("Terraform".into(), "terraform".into()), ("Terraform Vars".into(), "terraform-vars".into()), ]) } ``` I think it might be helpful in the future to have another way to map file extensions to specific language ids without having to create a new language configuration. ### UX Before ![CleanShot 2024-02-07 at 23 00 56@2x](https://github.com/zed-industries/zed/assets/45985/2c40f477-99a2-4dc1-86de-221acccfcedb) ### UX After ![CleanShot 2024-02-07 at 22 58 40@2x](https://github.com/zed-industries/zed/assets/45985/704c9cca-ae14-413a-be1f-d2439ae1ae22) Release Notes: - N/A --- Part of https://github.com/zed-industries/zed/issues/5098 2024-02-08 18:12:12 +00:00			`; https://github.com/nvim-treesitter/nvim-treesitter/blob/ce4adf11cfe36fc5b0e5bcdce0c7c6e8fbc9798a/queries/hcl/injections.scm`

			`(heredoc_template`
			`(template_literal) @content`
			`(heredoc_identifier) @language`
			`(#downcase! @language))`

			`; https://github.com/nvim-treesitter/nvim-treesitter/blob/ce4adf11cfe36fc5b0e5bcdce0c7c6e8fbc9798a/queries/terraform/injections.scm`
			`; inherits: hcl`