Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Local settings have to search inside comments as well #42332

Closed
isidorn opened this issue Jan 29, 2018 · 9 comments
Closed

Local settings have to search inside comments as well #42332

isidorn opened this issue Jan 29, 2018 · 9 comments
Assignees
Labels
bug Issue identified by VS Code Team member as probable bug settings-editor VS Code settings editor issues verified Verification succeeded
Milestone

Comments

@isidorn
Copy link
Contributor

isidorn commented Jan 29, 2018

  • 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.

@isidorn isidorn added bug Issue identified by VS Code Team member as probable bug settings-editor VS Code settings editor issues labels Jan 29, 2018
@isidorn isidorn added this to the January 2018 milestone Jan 29, 2018
@roblourens
Copy link
Member

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
Copy link
Contributor Author

isidorn commented Jan 29, 2018

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

@roblourens
Copy link
Member

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
Copy link
Member

@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
Copy link
Member

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
Copy link
Member

roblourens commented Jan 30, 2018

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
Copy link
Member

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
Copy link
Member

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
Copy link
Member

sandy081 commented Feb 1, 2018

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

@isidorn isidorn added the verified Verification succeeded label Feb 2, 2018
@vscodebot vscodebot bot locked and limited conversation to collaborators Mar 18, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Issue identified by VS Code Team member as probable bug settings-editor VS Code settings editor issues verified Verification succeeded
Projects
None yet
Development

No branches or pull requests

3 participants