Local settings have to search inside comments as well

[isidorn]

• If we introduce a brand new setting Bing is not aware of it for some time.
• The current approach is that we do not search in comments of local settings.

Put those two together and we have a corner case: I just introduced "workbench.multiSelectModifier" so Bing is unware of it, and puzzled users who see the ctrl + click behavior is different in the explorer will search for "explorer click" however there will be no results.
Due to that we always have to search in local settings inside comments and just merge that with bing settings and de-dupe.

[roblourens]

Did you do the search just now, or earlier? I can search for that setting now. New builds should be indexed within about 5 minutes of the mac build's completion. However there might be an extra lag right now because of a task that is still being completed on their end.

[isidorn]

@roblourens Right now
Search for "control", notice "workbench.multiSelectModifier" is not showing up

[roblourens]

Bing is actually returning it, but its score is too low to be displayed. There are a bunch of other matches with "control" in the key which is weighted higher. We cut off results that have a score less than 20% of the top score.

It is showing some matches that have "control" as the first word in the description which might be weighted higher than a word in the middle. I can ask them for clarification.

[roblourens]

@sandy081 I also was thinking about a compromise, where local filtering could continue to match the setting description, but using a simpler literal search, rather than the fuzzy search that we use to match setting keys and values.

This would let us keep specific matches like this, but reduce the noise coming from a fuzzy search with the large amount of text in the description.

Also, local filtering still needs to be useful when the machine is offline, or remote search is disabled. This seems like a case that should work.

Thoughts?

[sandy081]

One idea I have is to get back the local comment matches and change the ordering. We can have three buckets

1. Local and Key value matches
2. Local only comment matches
3. Bing matches

And we can show the results in the above order without dups?

[roblourens]

I'm in favor of applying some ordering to the local matches. We'd talked about this awhile back but I didn't get anywhere with it. But one thing I want to avoid is putting low-value local matches (from a too-fuzzy comment match) on top of high-value bing matches.

So maybe we combine that with what I said - do a simpler search inside descriptions, and rank them below other matches from the local search.

[roblourens]

I'll move this to feb because I don't think there's a big problem to be solved right now. e.g. queries like "control" are very unspecific and I don't know what the expected result is.

Also I guess we were already doing a less fuzzy search in descriptions than on keys.

[roblourens]

I am kind of worried about this hurting the experience when you are searching offline. Maybe it should rerun the search, including descriptions, if the remote search fails.

I'm also wondering if we should just reenable the description search as it was for Jan, and work on fancy ranking later.

[sandy081]

@roblourens agreed. Let's re-enable the comment search it and implement the smartness in next milestone.