Bug Description
The editor.action.nextSelectionMatchFindAction (Find Next Selection Match, default Cmd+F3/Ctrl+F3) and editor.action.previousSelectionMatchFindAction commands ignore the editor.find.seedSearchStringFromSelection setting. This setting is respected by the Find Widget (Ctrl+F) and other find actions, but not by the Selection Match Find actions.
Steps to Reproduce
- Set
"editor.find.seedSearchStringFromSelection": "selection" in settings
- Select some text (e.g.,
foo)
- Press
Cmd+F3 (or the keybinding for editor.action.nextSelectionMatchFindAction) — it correctly finds the next foo
- Paste from clipboard to replace the found match
- Press
Cmd+F3 again
Expected Behavior
With seedSearchStringFromSelection set to "selection", the action should not pick up the word at the cursor when there is no active selection. It should continue searching for the previous search term (foo).
Actual Behavior
The action picks up the word at/near the cursor position and uses that as the new search string, overwriting the previous search term. This is because the SelectionMatchFindAction.run() method hardcodes the call to getSelectionSearchString(editor, 'single', false), always passing false for seedSearchStringFromNonEmptySelection, which enables the word-at-cursor fallback regardless of the user's setting.
Root Cause
In src/vs/editor/contrib/find/browser/findController.ts, SelectionMatchFindAction.run() (line ~918) hardcodes:
const selectionSearchString = getSelectionSearchString(editor, 'single', false);
Compare with StartFindAction (line ~589) which correctly reads the setting:
seedSearchStringFromSelection: editor.getOption(EditorOption.find).seedSearchStringFromSelection !== 'never' ? 'single' : 'none',
seedSearchStringFromNonEmptySelection: editor.getOption(EditorOption.find).seedSearchStringFromSelection === 'selection',
Proposed Fix
Make SelectionMatchFindAction.run() respect the editor.find.seedSearchStringFromSelection setting, consistent with how all other find actions handle it. PR incoming.
| VS Code Version |
OS |
| 1.111.0 (latest main) |
All |
Bug Description
The
editor.action.nextSelectionMatchFindAction(Find Next Selection Match, defaultCmd+F3/Ctrl+F3) andeditor.action.previousSelectionMatchFindActioncommands ignore theeditor.find.seedSearchStringFromSelectionsetting. This setting is respected by the Find Widget (Ctrl+F) and other find actions, but not by the Selection Match Find actions.Steps to Reproduce
"editor.find.seedSearchStringFromSelection": "selection"in settingsfoo)Cmd+F3(or the keybinding foreditor.action.nextSelectionMatchFindAction) — it correctly finds the nextfooCmd+F3againExpected Behavior
With
seedSearchStringFromSelectionset to"selection", the action should not pick up the word at the cursor when there is no active selection. It should continue searching for the previous search term (foo).Actual Behavior
The action picks up the word at/near the cursor position and uses that as the new search string, overwriting the previous search term. This is because the
SelectionMatchFindAction.run()method hardcodes the call togetSelectionSearchString(editor, 'single', false), always passingfalseforseedSearchStringFromNonEmptySelection, which enables the word-at-cursor fallback regardless of the user's setting.Root Cause
In
src/vs/editor/contrib/find/browser/findController.ts,SelectionMatchFindAction.run()(line ~918) hardcodes:Compare with
StartFindAction(line ~589) which correctly reads the setting:Proposed Fix
Make
SelectionMatchFindAction.run()respect theeditor.find.seedSearchStringFromSelectionsetting, consistent with how all other find actions handle it. PR incoming.