Fix string splitter multi-caret handling

[Copilot]

Fix string splitter multi-caret handling

Plan

• Explore codebase and understand the issue
• Implement multi-caret position tracking during string splits
• Use IMultiSelectionBroker to set all caret positions after edits
• Use tracking points to handle position changes across edits
• Add tests for multi-caret scenarios
• Code review completed - addressed all feedback
• Security scan completed - no vulnerabilities detected

Summary

Fixed issue #64812 where the string splitter incorrectly handles multi-caret scenarios.

Problem:
When splitting strings with multiple carets:

1. Only the single-caret case was supported
2. Multi-caret scenarios resulted in incorrect caret positions
3. Primary caret could end up in the wrong location
4. Additional unwanted carets were sometimes added

Solution:

• Track new caret positions using ITrackingPoint as each split is processed (in reverse order)
• Tracking points automatically adjust positions as subsequent edits are applied
• After all edits are complete, get the final position of each tracking point
• Use SetMultiSelection extension method to set all carets at once

Changes Made

Modified SplitStringLiteralCommandHandler.cs:

• Use PooledObjects.ArrayBuilder for tracking point collection
• Renamed pooledSpans to finalCaretSpans for clarity
• After all splits complete, resolve tracking points to final positions
• Use textView.SetMultiSelection() to set all carets at once (with the last as the primary)

Simplified test TestMultiCaretPositionsAreAllSet:

• Now uses TestHandled helper method with markup
• Leverages existing test infrastructure for validation
• More concise and maintainable

Technical Details

The key challenge was handling position changes across multiple buffer edits:

• Spans are processed in reverse order (last to first) to avoid position invalidation of earlier positions
• Each split produces a new snapshot and a new caret position
• Using raw int positions would be incorrect because earlier edits shift later positions
• ITrackingPoint automatically adjusts positions as the buffer changes
• Final positions are resolved from tracking points in the final snapshot

Security Summary

✅ No security vulnerabilities detected by CodeQL scanner
✅ All code review feedback addressed
✅ All changes are minimal and focused on the specific issue

Original prompt

---

This section details on the original issue you should resolve

<issue_title>String splitter incorrectly handles multi-caret scenarios</issue_title>
<issue_description>Hitting enter in the following cases results in odd behavior:
1)

The primary caret is moved to the first location and additional 2 carets are added. I'd expect the primary stay the last and only 3 carets are present after splitting the string.

A couple of carets added that shouldn't be.

There is probably more cases like this.

Seems like the implementation should use IMultiSelectionBroker editor API instead of setting TextView.Caret.

</issue_description>

<agent_instructions>Copilot. It looks like our logic for determining the new text is correct. However, we mess up where teh caret is supposed to go. We currently have logic that bails out from setting the caret in the case where we have multiple initial carets in SplitStringLiteralCommandHandler.

What probably makes sense is to build up the final locations of the carets as we make each edit (or compute it all after we make all the edits). Then use some api to set all the carets at the end.

See IMultiSelectionBroker which could be helpful here. Note: this may be complex since we compute from end to start, and earlier edits could affect the positions of later carets. Maybe this is easy to compute, but maybe not.</agent_instructions>

Comments on the Issue (you are @copilot in this section)

• Fixes String splitter incorrectly handles multi-caret scenarios #64812

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[CyrusNajmabadi]

@copilot please do using var _ = ArrayBuilder<ITrackingPoint>.GetInstance(spans.Count, out var trackingPoints); (or whatever the normal pattern is in this code for a pooled array of the right length.

[Copilot]

Done in ca3e79c. Changed to use PooledObjects.ArrayBuilder<ITrackingPoint>.GetInstance(spans.Count, out var trackingPoints) with the fully qualified namespace to avoid ambiguity.

[CyrusNajmabadi]

@copilot rename this to finalCaretSpans

[Copilot]

Done in ca3e79c. Renamed to finalCaretSpans.

[CyrusNajmabadi]

@copilot instead of manually computing the positions, put them in the expectedOutput with [||] markers as well. Then use the MarkupTestFile helpers to extract out the text content and caret positions of the expected outcome to validate against.

[Copilot]

Done in ca3e79c. Simplified the test to use TestHandled helper which automatically validates both the text output and caret positions using the [||] markers.

[CyrusNajmabadi]

@dibarbet ptal.