NavTo: Enhance "Current Document" scope with results from base types and partial types

[sandyarmstrong]

Background and Motivation

A common user pattern in Visual Studio is to configure "Go to Member" in All-in-one Search to use the "Current Document" scope by default. But some users have reported being confused when members from the current type they're looking at don't show up. Typically these additional members are actually declared in base types or partial types, but users often don't memorize which is declared where, and toggling the scope in AIOS is an extra step they don't feel they should have to make.

Including these members in the "Current Document" scope would add data that feels like it is currently missing.

Proposed Feature

Enhance the navigation service used to implement ISearchItemsSourceProvider for AIOS such that when the "Current Document" scope and the "Members" filter is selected, instead of taking it literally, instead include the following:

• For each type declared (fully or partially, inner or outer) in the current file:
  • All of its members
    • Regardless of which file they are declared in, or whether they come from a base type

Open Questions

Is anything missing from the above list?

The only other thing that came to my mind in the category of "stuff I know this file does but it turns out it's not really from this file" is extension methods, but I don't feel like they make sense here, as they're not really part of the type.

Should this also work for the "Types" filter?

It's probably not as necessary/useful, but perhaps it would be more consistent? I'd probably go with whatever is easier to implement. :-)

[CyrusNajmabadi]

I discussed thsi offline with Sandy. Initially i thought this might not be feasible due to the reliance on semantics, given that our NavTo code operates entirely syntactically/textually today.

However, it does seem like we can do something viable here. First, remember that this is only when the 'current document scope' is passed through the search query. In that case, we can do the following:

1. Kick off the normal NavTo textual search system on the actual 'current document'.
2. Concurrently, we can kick off a new, special, semantic search for this scenario. This "semantic current doc search" would analyze the current file semantically, looking for partial types within it, and examining the inheritance hierarchy of the types declared in the file. From this, it could come up with the next set of "related documents" to examine, specifically only returning documents not equal to the true 'current document'.
3. We'd then perform the normal NavTo textual search on those 'related documents'.

Benefits of this approach:

1. Normal NavTo code is unaffected.
2. Textual results from the current file still are returned immediately without interference.
3. We do not get duplicates we have to worry about as the semantic search only returns other documents to consider.
4. The other documents are still searched normally.

In a sense, this is a normal NavTo search, just scoped down to a small cohort of files instead of just a single file. And where one file is still prioritized and run immediately, while the cohort set is discovered and eventually passed on for the secondary results.

I would estimate this at 1-2 days of work tops.