Vscode: Word wheeling in file search feels disruptive

[martellaj]

I noticed in the latest Insiders build that a search is happening per keystroke. I understand the idea behind this, but it feels disruptive as a user.

Not really a bug report, but just an opinion from an Insiders user.

[usernamehw]

Issue reference: #46326

Disable:

"search.searchOnType": false,

Configure delay:

"search.searchOnTypeDebouncePeriod": 1500,

[JacksonKearl]

Thanks for the feedback, as @usernamehw suggested, you can change the debounce period or disable it entirely. We're actively figuring out what the default should be for the debounce, do either of you have a number you prefer? I've heard from several people that the current 300ms is too fast.

[usernamehw]

500

[martellaj]

@JacksonKearl I don't think it makes sense to have it enabled by default in a code editor. In something like mail search or web search, it may make sense because partial matches may be helpful. However, for code, I often know exactly the name of a function or variable I'm searing for, so any searches that happen before I finish just seem unnecessary.

For example, if I want to search for a function called _lazyGetSuggestions_ - anything for "lazy" will return thousands of matches in my repository and just won't be helpful.

I'm actually curious if you're all tracking success for this feature, or just an idea you wanted to try out. I work on Outlook search, and I know the desktop team has recently removed word wheeling as part of their search experience and didn't see a regression in search success. OWA has never had it.

In any case, thanks for pointing out there's a way to disable it!

[martellaj]

😂

I just checked out the original issue and see there is some desire for this feature - which proves my opinion is just an opinion. 😊 I still think the jury is out whether or not to enable it by default though.

[usernamehw]

I also think search.searchOnType should be false by default.

[JacksonKearl]

@martellaj @usernamehw We may disable it by default for Stable, but for this Insiders we'll be keeping it enabled by default to maximize exposure and feedback.

I'm currently working on #84547, which will make the "receive results, then type more to filter them down" presentation smoother, which should make the feature less distracting. It will also add an additional ~100ms delay between search being triggered and the UI rendering results, which might make the 300ms debounce more reasonable feeling. Though we may yet change it to be 400 or 500.

One thing to note is that prior to this change, the global text search was the only search across the app that required manually triggering the search, which is a bid odd from a design perspective.

[JacksonKearl]

Closing this out as the setting can be disabled and the refresh UI was made less jarring.