Improve and unify selection updating behaviour to handle overlapping ranges #138
Description
The problem
The code in updateSelections.ts that actually updates the selections is a bit picky about what it will update. It works if all edits either
- have no overlap with the given selections, or
- have a range that is identical to one of the selections
However, if, for example, change.range.start is not before selection.range.start, but is before selection.range.end, and not the exact same range, the selections will silently not be updated
One example where the current logic breaks: if the commentLines action is applied with a target that is the entire line, the that mark ends up not getting moved to the right
In addition, we do not use this new selection updating code in the NavigationMap.
The solution
We would like to do the following:
Improve the selection updating code
There are lots of ways we could get fancy, but let's start with something simple. The approach is to take each selection, and split it into start and end positions. Then for each of these positions, if the end of the change range is before or equal to the position, we shift it. If the change range contains the position, we can have an option passed in by the caller to determine what to do, either expand to include it, contract to exclude it, or throw an exception / remove the selection. Could maybe just steal the OpenOpen / OpenClosed etc stuff that VSCode does with decorations
This solution at least allows us to handle changes that are contained entirely within the selection.
- Improve selection updating code
Use selection updating code in the navigation map
- Use selection updating code in the navigation map