Daniel Banck
9e538e7916
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  ### UX After  Release Notes: - N/A --- * Part of https://github.com/zed-industries/zed/issues/5098
Zed
Welcome to Zed, a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.
Installation
You can download Zed today for macOS (v10.15+).
Support for additional platforms is on our roadmap:
- Linux (tracking issue)
- Windows (tracking issue)
- Web (tracking issue)
For macOS users, you can also install Zed from Homebrew:
brew install zed
Developing Zed
Contributing
See CONTRIBUTING.md for ways you can contribute to Zed.
Licensing
License information for third party dependencies must be correctly provided for CI to pass.
We use cargo-about to automatically comply with open source licenses. If CI is failing, check the following:
- Is it showing a
no license specifiederror for a crate you've created? If so, addpublish = falseunder[package]in your crate's Cargo.toml. - Is the error
failed to satisfy license requirementsfor a dependency? If so, first determine what license the project has and whether this system is sufficient to comply with this license's requirements. If you're unsure, ask a lawyer. Once you've verified that this system is acceptable add the license's SPDX identifier to theacceptedarray inscript/licenses/zed-licenses.toml. - Is
cargo-aboutunable to find the license for a dependency? If so, add a clarification field at the end ofscript/licenses/zed-licenses.toml, as specified in the cargo-about book.