-
Notifications
You must be signed in to change notification settings - Fork 109
Add support for vars, stack, deploy and search #201
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Add support for vars, stack, deploy and search #201
Conversation
Correctly identify different types of terraform files: - terraform-vars - terraform-stack - terraform-deploy - terraform-search Fixes: - hashicorp/terraform-ls#1838 Refs: - https://github.com/hashicorp/terraform-ls/blob/c20eef80eac1d158e0fc45d7f6de23602104a3f8/docs/language-clients.md#language-ids
afdce37 to
10a20fd
Compare
|
this is kinda silly, isn't it? The terraform language server has made a dubious choice that it wants 6 (six!) different language identifiers, and now all editors are expected to go along with that. I don't love it. Why doesn't the terraform language server accept the language identifier "terraform", and look at the suffix itself (in the uri) to deal with these variations? Did anyone try asking them that already? Edit: 5, not 6. But the point stands. |
|
I found discussions related to the implementation where different options were considered (warning: a lot of comments to go through): |
|
I don't see different options being considered in those discussions |
|
You are right, I've read again carefully and found this one as the most relevant comment (not options but justification): |
|
Also, thinking about the end user UX setting language ID by the client makes sense as there are cases when file extension is not present, for example, when I set file type at runtime ( |
|
Treating terraform as though it were five separate languages strikes me as absurd. It's barely even one! - it's all HCL I am not aware of any other language or language server that expects such fine-grained divisions eg so far as I know c is c, whether it is In a world where this particular language server implementation gets to set the rules, your pull request makes sense. But that does not seem like a reasonable world. What if someone else wants to write a language server for terraform? are they too obliged to follow this convention? I'll sit on this for a bit, I don't know how much trouble it is really worth. If you wanted to head over to hashicorp/terraform-ls#1838 and suggest that they could fix this by not making such demands of every text editor, that'd be great. |
|
The decision on their side is made and it was made long time ago. I see no reason for them to revisit it now and I don't see myself trying to convince them, not without strong arguments on why they have to break backwards compatibility now. I'm hoping for the language server for tf and tofu (which are my primary tools these days) just work andI created this PR with a hope to fix something which is bothering me for quite some time now. If you see another sensible way to fix the issue I'm all for it. |
|
the reason for them to revisit it now would be that it was a poor decision which has negative consequences it's not just users of this plugin - as I say, every editor is being asked to go along with this. I see emacs users in that thread too. fwiw I personally don't use this plugin at all any more - most of it has been absorbed into vim / neovim. And for better or worse, the author of this proliferation of filetypes has persuaded them to go to two (though not yet five!): neovim/neovim#19417 So you could likely fix the issue simply by not using this plugin |
|
Thank for the link. I use vim, not neovim, so I still need the plugin. |
|
keep following the links, it's all in vim too |
|
I've just tried removing the plugin and yes, ftdetect works but no syntax highlighting and I'm not sure about indent |
|
I think I'd be more inclined to accept a pull request that left all the not-just-plain-terraform files as Then the only change that would be needed would be to treat That gives up on this language server being useful for tfvars files when used with this plugin: but apparently that is the case anyway so no great loss. If and when someone wants to make the case that terraform really is five separate (but identical) languages we can have this conversation again. |
Processing tfvars by the language server is exactly what I need with all go-to-definition and autocomplete working.
At this point I don't care about terraform-stack, terraform-deploy and terraform-search, I've added them for completeness because I found them in the docs. I can remove these it this works for you. |
|
@dimbleby any thoughts? |
Correctly identify different types of terraform files:
Fixes:
Refs: