Fix infinite looping in notebook addFindMatchToSelection (Cmd+D)

[Copilot]

Problem

When using Cmd+D (Add Selection to Next Find Match) in notebooks, the operation keeps looping indefinitely instead of becoming a no-op once all find results are covered by selections. This differs from regular editors where pressing Cmd+D stops being effective when all matches are already selected.

Root Cause

The issue was in the findAndTrackNextSelection method in notebookMulticursor.ts. When in the Selecting state, the method calls notebookTextModel.findNextMatch() which cycles through matches infinitely, unlike regular editors where findNextMatch returns null when no more unique matches are available.

Solution

Added a check before calling findNextMatch that compares:

• totalMatches: Count of all available matches in the notebook
• totalSelections: Count of all current selections across tracked cells

When totalSelections >= totalMatches, the method returns early (no-op), preventing the infinite loop and matching the behavior of regular editors.

// Check if all matches are already covered by selections to avoid infinite looping
const allMatches = notebookTextModel.findMatches(this.word, false, true, USUAL_WORD_SEPARATORS);
const totalMatches = allMatches.reduce((sum, cellMatch) => sum + cellMatch.matches.length, 0);
const totalSelections = this.trackedCells.reduce((sum, trackedCell) => sum + trackedCell.matchSelections.length, 0);

if (totalSelections >= totalMatches) {
    // All matches are already selected, make this a no-op like in regular editors
    return;
}

Testing

The fix ensures that pressing Cmd+D in notebooks will stop being effective once all find results are covered by selections, exactly like in regular text editors. The operation becomes a no-op when all matches are already selected, preventing the infinite cycling behavior.

Fixes #235117.

[Yoyokrazy]

this isn't optimal, since we don't want to do an entire extra findMatches call each time we check this and same with the iteration overTracked cells for totalSelections. Can we just record allMatches at the beginning of this whole process? ie when we're going from idle into selecting? the first case? Then each time we successfully add another match we can just incremement and then its a lot better, perf-wise

[Copilot]

Good point! I've optimized the performance by recording allMatches count once during the idle→selecting transition and using a cached counter instead of recalculating on every Cmd+D press. This eliminates the expensive findMatches() call and tracked cells iteration. See commit 2dda55d.

[Yoyokrazy]

built and verified fix