Roslyn: pre-selection should favor in-scope symbols

Created on 20 Apr 2019  路  4Comments  路  Source: dotnet/roslyn

From feedback

For some reason it tends to pre-select import completions over regular ones.

image

It seems the reason unimport one is favored in this case is because it's considered a better match based on current algorithm (which takes suffix "<>" in to account as well)

Area-IDE Bug IDE-IntelliSense Resolution-Fixed

Most helpful comment

however, we have two imperfect matches. One of them is a substring match, and another is a camel case match. I would like locally available variables to have priority over external items who also have imperfect match kind.

say i have a prefix match with an existing symbol, and an exact match with an import-symbol, which should win?

The 'exact match' seems better (it's exact after all), but a user could have easily just wanted to write a quick prefix that would normally hit the existing symbol.

I think we shoudl basically always defer to non-import matches. Because that's the behavior the user would have gotten prior to import-matches being an option. So import matches (similar to extension methods for the compiler) are always 'second tier' results. They're to solve a problem if no existing symbols solve the problem. This also forces users to be more explicit about selecting them, indicating awareness and acceptance of the addition of the import.

All 4 comments

I've hit this a lot working with the roslyn APIs, especially in unit tests in the compiler layer where there are 4 different InvocationExpressionSyntax classes in differing namespaces.

I've also ran into this issue. I'd like the local LastReturnedResults to be selected:
image

I still want the exact match to be the preferred item. In this case, however, we have two imperfect matches. One of them is a substring match, and another is a camel case match. I would like locally available variables to have priority over external items who also have imperfect match kind.

however, we have two imperfect matches. One of them is a substring match, and another is a camel case match. I would like locally available variables to have priority over external items who also have imperfect match kind.

say i have a prefix match with an existing symbol, and an exact match with an import-symbol, which should win?

The 'exact match' seems better (it's exact after all), but a user could have easily just wanted to write a quick prefix that would normally hit the existing symbol.

I think we shoudl basically always defer to non-import matches. Because that's the behavior the user would have gotten prior to import-matches being an option. So import matches (similar to extension methods for the compiler) are always 'second tier' results. They're to solve a problem if no existing symbols solve the problem. This also forces users to be more explicit about selecting them, indicating awareness and acceptance of the addition of the import.

I think we shoudl basically always defer to non-import matches

I like the predictability of this approach.
After all, user can use arrow keys to select desired item, or keep typing until local variable gets filtered out.

Was this page helpful?
0 / 5 - 0 ratings