Nested block autocompletion has incorrect indent level

[amasover]

Server Version

0.3.2

Terraform Version

0.12.26

Client Version

Emacs with lsp-mode 20200612.455 from Melpa

Terraform Configuration Files

(Resulting code when autocompleting blocks):

resource "aws_appmesh_mesh" "test" {
  spec {
  egress_filter {
  0
}
}
}

Log Output

https://gist.github.com/amasover/ed2ba0c211bb84cc612f2acc21c79933

Expected Behavior

The spec and egress_filter blocks should be indented at the correct level, like so:

resource "aws_appmesh_mesh" "test" {
  spec {
    egress_filter {
      0
    }
  }
}

Actual Behavior

It seems that autocompleted nested blocks are indented as if they were at the base level (i.e., as if they were not nested).

Steps to Reproduce

1. Open a Terraform file in Emacs.
2. Create a resource that has a nested block available (for example, aws_appmesh_mesh or azurerm_container_group.
3. Start creating a new block inside that resource, and autocomplete it

[radeksimko]

I have yet to reproduce this one in Emacs and potentially other language clients, but I just want to note that this doesn't seem to affect Sublime Text nor VSCode.

I think the best way forward here would be understanding why the behaviours differ between clients at first.

One workaround would be to leverage some auto-formatting support in the client (which would just call textDocument/formatting server method), which should re-align these blocks.

[amasover]

I opened an issue on lsp-mode as well. Not sure if this is something that needs to be fixed on the client or server, but hopefully it will help us track the issue and get to the bottom of why things are different.

Something yyoncho (maintainer of lsp-mode) suggested is to compare output logs from VSCode vs lsp-mode, so I've included both on the opened issue.

I imagine right now y'all are maybe still a little more focused on getting the VSCode plugin running smoothly, so I definitely appreciate the time you're taking on some of my emacs-specific questions/issues.

[radeksimko]

Something yyoncho (maintainer of lsp-mode) suggested is to compare output logs from VSCode vs lsp-mode, so I've included both on the opened issue.

That sounds like a good plan 👍

Just to clarify - I wasn't suggesting it's the Emacs plugin misbehaving, it could also be the other way around, because many other plugins are dedicated "Terraform plugins" (unlike lsp-mode), or rely on such plugins in one way or another. It may be this extra logic these dedicated plugins bring that makes them behave differently.

I don't know how the Emacs plugin integrates with Emacs, but Sublime Text specifically has a generic LSP plugin, but still relies on another dedicated plugin to do syntax highlighting and possibly more, because it predates any language server.

I am not aware of the VSCode extension having any extensive understanding of HCL beyond syntax highlighting. It may be the syntax highlighting though that gives VSCode enough context to change some UI behaviour. We also noticed that while VSCode normally does "on-type-completion", it doesn't do that within block labels. The root cause may be the same as the one behind these extra whitespaces.

These dedicated plugins are still vital at least until LSP supports syntax highlighting. Either way I would like to see all these dedicated plugins eventually reducing their feature set by moving it into the server and bringing some feature parity and consistent support across all editors.

I imagine right now y'all are maybe still a little more focused on getting the VSCode plugin running smoothly, so I definitely appreciate the time you're taking on some of my emacs-specific questions/issues.

That is mostly true, but this insight is incredibly helpful to ensure the language server can serve all editors, so keep the non-VSCode feedback coming, please! 😄

[radeksimko]

Not sure if it's the best solution, but I wonder if supporting on-type formatting would help here:
https://microsoft.github.io/language-server-protocol/specifications/specification-current/#textDocument_onTypeFormatting

I guess it depends on whether confirming completion is generally treated as "typing" from client's perspective, i.e. whether the client would even trigger that event.

[amasover]

It looks like this is fixed now in lsp-mode, so I think this issue can be closed.

emacs-lsp/lsp-mode#1935

It looks like the reason it worked differently in VSCode is because they're doing some magic indentation client-side:

microsoft/language-server-protocol#83

So in Emacs it seems we'll be doing that client-side indentation via yasnippet's indent line. Though there's some debate over whether any client should really be doing that indentation client-side. VSCode isn't really following the spec here.

There's still a few differences between Emacs lsp-mode and VSCode behavior that I brought up here:

emacs-lsp/lsp-mode#1805 (comment)

I'm thinking the autocompleted "1" and "3" are possibly a little confusing (are those coming from required number of fields in the provider schema?)

resource "1" "name" {
  3
}

But at this point indentation at least is working much better 😄

[radeksimko]

Though there's some debate over whether any client should really be doing that indentation client-side. VSCode isn't really following the spec here.

That's my thinking as well, but I don't know yet what's the best way of fixing it without breaking other clients.
I'm glad it's working for you now though and maybe this ship has already sailed and the only pragmatic solution is to make sure most clients mimic the same behaviour regardless of how correct it is?

I plan to revisit how clients highlight and interpret HCL-based languages in general as part of #50

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the context necessary to investigate further.