Change:
We currently require and a space to use the search quick access. Although files could start with (noted in ), we should also consider how often this would be the case. Other picks like the command palette don't have a space, so perhaps it's expected to not have a space.
I contribute to an extension the implements a FileSearchProvider onto code environments (InterSystems IRIS and relatives) where "files" whose names begin with % are common since that naming convention is used for library packages. It would be a problem for our users if an attempt to quick-open, say, failed because the request was now interpreted as a TextSearchProvider quick-search instead. Pinging for info.
John described the concern perfectly. This will lead to a lot of confusion for our users when the FileSearchProvider and TextSearchProvider APIs are finalized (which we hope is soon!). I see how having the space is inconsistent, so is there another "symbol" character that can be used other than %? Or is there a clear way to "escape" that % so it's not a search trigger?
How about instead?
You can still search for using if we decide not to have a space. Would that be okay?
To quick open files that start with %, users would have to enter instead of ? Or would it be ?
"
edit: for some reason, I missed some of the above comments. That makes sense. I wonder if there's another symbol that is usually invalid in filenames. '=' seems sort of awkward in this situation imo
I talked to the team about this - a popular idea was to just do ("search" and a space) instead of a symbol. Sort of like . That way, it's more clear and follow an existing pattern we have.
I've been talking to team members about this whole "what should trigger quick search" issue since it's a little tricky to find something that intuitive and wouldn't conflict with user experiences. Some notes from this discussion: Having + isn't consistent with any of the behavior that we have for symbols that trigger quick accesses (ie: ) We could use a keyword like + like we have + for the debug quick access, but we think that having a whole word would be hard for future use cases like having something before the trigger symbol/word. For example, you can have <img width="629" alt="image" src=""Similarly, we can have if we used a percentage, and this would look really awkward if this was replaced with the string Exploring other characters, ones like , , etc. seemed quite common in filenames. We considered , but that sort of seemed like it was calculating something; we also considered , but it would be confusing if we were to introduce regex to the quick search. Any opening/closing bracket or brace would look odd without the other. To escape this behavior, you can actually use a space before the character to search for it (I was wrong above- although you can use a to escape, you can also use character. So to escape, which is a lot easier than ). We should probably document this somewhere if isn't already documented. From this, using without a space seemed like the best way to go forward. Additional things discussed: Why is the quick chat not triggered like quick access commands? The other command center options do so. This is because quick chat is a special case and the input used in chat is quite different from the basic one in the quick open. Its UX is also much different from the other quick accesses. When developing a feature for the command center, anything that can be made as a quick access should aim to follow the pattern of most quick accesses ( triggering the feature). In the case of quick search, it should also be triggered like other quick accesses because it allows you do as mentioned above. The command center currently says by default, but it only searches files - in the future, it should be pretty intuitive that it searches files by default, not text in files. cc
I guess it'll be tolerable for our users to have to prefix with a space if they're trying to quickopen something beginning with %.
Since quick search is being actively refined, is there any chance of () making the jump to stable soon?
I have been meaning to finalize and as soon as I can, but asks from the team are taking some precedence. For example, quick search was originally introduced so that it can possibly used for AI integration in the future (which is a higher team priority).
Thanks for the update, I'm glad to hear that they are still on your radar!

Discussion:
import { ITextQueryBuilderOptions, QueryBuilder } from 'vs/workbench/services/search/common/queryBuilder'; import { IPatternInfo, ITextQuery, VIEW_ID } from 'vs/workbench/services/search/common/search'; <del> export const TEXT_SEARCH_QUICK_ACCESS_PREFIX = '% '; </del> <ins> export const TEXT_SEARCH_QUICK_ACCESS_PREFIX = '%'; </ins> const DEFAULT_TEXT_QUERY_BUILDER_OPTIONS: ITextQueryBuilderOptions = { _reason: 'quickAccessSearch',