Improve FileSearchProvider pattern documentation with explicit matching guidance

[Copilot]

Fixes #226668

The FileSearchQuery.pattern and FileSearchProvider2.provideFileSearchResults documentation lacked clear guidance on pattern interpretation, unlike WorkspaceSymbolProvider which explicitly specifies matching behavior.

Changes

Updated documentation across public APIs and internal types to provide explicit matching guidance:

Pattern interpretation guidance added:

• Interpret pattern in a relaxed way (editor applies own scoring)
• Match case-insensitive
• Check characters appear in order in candidate paths
• Don't use strict prefix/substring matching
• Empty pattern returns all files

Files updated:

• vscode.proposed.fileSearchProvider.d.ts - FileSearchQuery.pattern
• vscode.proposed.fileSearchProvider2.d.ts - FileSearchProvider2.provideFileSearchResults
• searchExtConversionTypes.ts - Internal FileSearchQuery interface
• searchExtTypes.ts - Internal FileSearchProvider2 interfaces (also fixed incorrect @param references to non-existent parameters)

Documentation now matches WorkspaceSymbolProvider style and clarity, eliminating ambiguity about matching semantics.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>The docs for provideFileSearchResults should provide guidance how to interpret pattern</issue_title>
<issue_description>Testing #226668

Today, the docs just say "The search pattern to match against file paths." This leaves a lot of room for speculation and it's not clear if matching is substring, startWith, case-sensitive, fuzzy etc.

For the WorkspaceSymbolProvider api we have very similar challenge and with it we are very explicit how the search string should be interpreted:

vscode/src/vscode-dts/vscode.d.ts

Lines 3599 to 3602 in 7473068

	* The `query`-parameter should be interpreted in a *relaxed way* as the editor will apply its own highlighting
	* and scoring on the results. A good rule of thumb is to match case-insensitive and to simply check that the
	* characters of *query* appear in their order in a candidate symbol. Don't use prefix, substring, or similar
	* strict matching.

</issue_description>

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

• Fixes The docs for provideFileSearchResults should provide guidance how to interpret pattern #226730

---

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

[dmitrivMS]

@copilot wrong place, the issue was about this param doc comment:
https://github.com/microsoft/vscode/blob/94f869842859c273491a8067d81f82f5fb30709a/src/vscode-dts/vscode.proposed.fileSearchProviderNew.d.ts#L80C4-L80C68

[Copilot]

@copilot wrong place, the issue was about this param doc comment:
https://github.com/microsoft/vscode/blob/94f869842859c273491a8067d81f82f5fb30709a/src/vscode-dts/vscode.proposed.fileSearchProviderNe...

The file vscode.proposed.fileSearchProviderNew.d.ts doesn't exist in the repository. Could you clarify which file you're referring to?

I updated:

• vscode.proposed.fileSearchProvider.d.ts - FileSearchQuery.pattern field documentation (lines 14-24)
• vscode.proposed.fileSearchProvider2.d.ts - @param pattern in provideFileSearchResults method (lines 80-84)

Both now have the same guidance as WorkspaceSymbolProvider. Which location should I focus on instead?

[gjsjohnmurray]

@copilot wrong place, the issue was about this param doc comment: https://github.com/microsoft/vscode/blob/94f869842859c273491a8067d81f82f5fb30709a/src/vscode-dts/vscode.proposed.fileSearchProviderNew.d.ts#L80C4-L80C68

@dmitrivMS maybe #232443 explains the confusion between New and 2

Anyway, I am pleased to see signs of fresh activity on the (File|Text)SearchProvider APIs 🤞🤞