dotnet / roslyn

The Roslyn .NET compiler provides C# and Visual Basic languages with rich code analysis APIs.
https://docs.microsoft.com/dotnet/csharp/roslyn-sdk/
MIT License
19.07k stars 4.04k forks source link

Completion matching does not support abbreviated identifiers #46677

Closed vsfeedback closed 4 days ago

vsfeedback commented 4 years ago

This issue has been moved from a ticket on Developer Community.


Fuzzy completion is very convenient to use since it can reduce the characters I need to type for getting right item. Intellisence's fuzzy matching is not working well with C#, at least no as good as it is with C/C++. VSCode even VIM did better than intellisence at this point e.g. when I want get "Console", but there's a lot of items start with "conso". In C/C++ , I can type "cle" to get "Console" on the top of Intellisence's list, but this trick does not work in C#'s Intellisence. It's seems unnecessary for short item like "Console", however , this really matters when playing with big projects with a huge amount of long items starts with same substring because you have to type more and scroll a lot for getting a right item!


Original Comments

Feedback Bot on 8/9/2020, 10:52 PM:

We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.

Feedback Bot on 8/10/2020, 09:56 AM:

Thank you for sharing your feedback! Our teams prioritize action on product issues with broad customer impact. See details at: https://docs.microsoft.com/en-us/visualstudio/ide/report-a-problem?view=vs-2019#faq. In case you need answers to common questions or need assisted support, be sure to use https://visualstudio.microsoft.com/vs/support/. We’ll keep you posted on any updates to this feedback.


Original Solutions

(no solutions)

CyrusNajmabadi commented 4 years ago

This is an odd example as Con generally will pick Console (esp. with IntelliCode). C#'s algorithm it designed to easily type abbreviated portions of long word sequenes. but with the general approach that each chunk you provide is a Exaxt/Prefix/Substring match for some chunk. Matching arbitrary letters against a single chunk may be possible, but may also be much noisier. i.e. the number of hits for cle (esp. given it's likely a substring match) will likely outweight it's value.

sharwell commented 4 years ago

Con is a prefix match, as opposed to abbreviations like cnsl. When I was working on pattern matching in the past, abbreviations were very helpful, especially for their ability to handle accidental omission of characters (typos).

jasonmalinowski commented 4 years ago

We discussed this in our design meeting, and ultimately concluded we should just give it a shot. One wrinkle @CyrusNajmabadi called out was the Navigate To API requires us to return a 'match kind' in the API, and that's used to determine which match is 'better' across multiple providers; we'll have to be careful to pick an appropriate one as we may not want these matches appearing above something more important.

CyrusNajmabadi commented 4 years ago

Also, whoever does the impl here: this must not allocate when doing a check against a particular string. We performance these operations against literally every symbol name in teh entire solution. Any allocations we perform against each string will saturate memory and majorly slow this down.

Note: it is ok to do an up front allocation if necessary to build any sort of 'acceleration structure' to help with the operation. Those one time costs are fine. It's a cost per-match that is not ok.

CyrusNajmabadi commented 4 days ago

Closing out due to lack of broad feedback.