Ignore LineDecoration order when comparing #108379
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR fixes #80666 . I was really hoping that this will be fixed for September update, but no-surprisingly, was pushed back.
Disclaimer
Be aware that I was unable to test this in vscode build itself, because It's very problematic to get build running. I've tested similar code in debugger's conditional breakpoint and this code in simplified test scenario. But yeah, real-life test is necessary.
The problem
LineDecoration
s often are changing order when there isafter
decorator, which messes up drag&drop. With Error Lens extension this is annoying as... something very annoying. More info #80666 (comment)The solution
There are 2 approach for this: first to sort every
LineDecoration
array, but I've settled for second: make comparison order-proof. For starters changes are done in one place, but also future changes will less likely break this.I've tried to optimize this as good as I could, but maybe this may be improved further.
The elephant
Isn't order important somehow?
No. Which style is used should be determinated by order of CSS rules, so even in different order, decorators should show-up in the same way. If this wasn't the case, this would cause weird style flashing.
The performance
For
arr.length <= 1
this could be even faster. For arrays in correct order above 2 elements, this will have overhead of additional array (bSeen
), but still should be the same number of comparisons (w/_equals
). On the other hand usually there isn't that many visible elements with 2+ decorators.However for arrays with different order this will also prevent re-rendering these lines - which happens more often than you may think.
@alexdima This is probably for you to take a look. Or maybe @rebornix ?