This PR improves handling of un-indented arrays by fixing two similar scenarios.
Scenario 1
Given
steps:
- task: PowerShell@2
|
We should be completing properties for the object that task is a part of, not the list under steps.
Previously, the parent algorithm would see that the current indentation == the configured indentation and incorrectly choose the parent list as the "real" closest node, despite the cursor clearly being more indented than the list.
Now, we also verify that the indentation of the current node equals the cursor indentation before deciding to look at the parent.
Scenario 2
Given
steps:
- task: PowerShell@2
|
It is less clear if we want to continue adding onto the array, or if we want to complete schemas that are siblings of steps.
What we do know, however, is that we cannot suggest array items without the leading array indicator. #804 added that incorrect behavior while trying to fix a subset of Scenario 1. Now with Scenario 1 fixed, #804 can be reverted which also fixes Scenario 2.
What issues does this PR fix or reference?
N/A, I caught both of these issues when trying to catch azure-pipelines-language-server back up with yaml-language-server.
Is it tested? How?
Added unit tests and confirmed that all tests pass.
What does this PR do?
This PR improves handling of un-indented arrays by fixing two similar scenarios.
Scenario 1
Given
We should be completing properties for the object that
taskis a part of, not the list understeps.Previously, the parent algorithm would see that the current indentation == the configured indentation and incorrectly choose the parent list as the "real" closest node, despite the cursor clearly being more indented than the list.
Now, we also verify that the indentation of the current node equals the cursor indentation before deciding to look at the parent.
Scenario 2
Given
It is less clear if we want to continue adding onto the array, or if we want to complete schemas that are siblings of
steps.What we do know, however, is that we cannot suggest array items without the leading array indicator. #804 added that incorrect behavior while trying to fix a subset of Scenario 1. Now with Scenario 1 fixed, #804 can be reverted which also fixes Scenario 2.
What issues does this PR fix or reference?
N/A, I caught both of these issues when trying to catch azure-pipelines-language-server back up with yaml-language-server.
Is it tested? How?
Added unit tests and confirmed that all tests pass.