Language Status indicator

[jpogran]

This sets a busy status when finding out the terraform version, which approximates a loading status for the extension because the request for status happens after all the other requests happen "in the background". So, we get a loading bar for the extension in the lower right hand corner.

Screen.Recording.2023-07-20.at.1.23.37.PM.mov

[jpogran]

Repointed to main instead of experimental #1540

[dbanck]

Nice work! Just two small suggestions.

And one nit: we have three loading indicators, one per version, but currently all are spinning until we fetch all versions.

If there is no easy fix for that, we can keep it that way.

[jpogran]

And one nit: we have three loading indicators, one per version, but currently all are spinning until we fetch all versions.

That why I said this approximates not is a loading status indicator.

We have a busy indicator for terraform-ls by using client.onDidChangeState, but since terraform-ls returns initialized almost immediately the indicator goes from busy to running faster than the eye can see. However, we are still processing jobs in the background that prevent new requests from being processed, so we aren't truly 'ready'. So relying just on the server to say it's ready doesn't actually tell us it is.

The request for the terraform version resolution is queued behind all the other work we initiate at start and returns when most of that is finished. This simulates terraform-ls still being 'busy' by having the busy indicator set for both terraform-ls status and the terraform version. This means all three are busy at the same time, but more accurately portrays the current status of terraform-ls.

I could have not set the terraform version as busy and left it blank until it's filled, and only set terraform-ls to busy. This would be only one busy icon, so would be less moving parts. But, I think this leaves the state of the terraform version confusing, is it blank because we couldn't find it or because we're still waiting?

A more accurate implementation could have terraform-ls not return initialized until it has finished the background jobs, which would make the client.onDidChangeState show busy until it was ready. This would require some significant changes to initialization of terraform-ls.

Another accurate implementation would utilize the custom request functionality to have the client send a request to terraform-ls asking about it's status. The scheduler can return how many jobs are pending and we can use that to update the busy indicator. This would require less changes than changing initialization, but still is a bigger lift than this PR.

We had time for this approximation right now.

[dbanck]

👍 That makes sense. Appreciate the additional context!

[github-actions]

I'm going to lock this pull request 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 related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.