[MonoDevelop] Code completion matching - input needed

[Mike Krüger]

Hi
> I wish this discussion was made before changing the behavior of the
> Navigate dialog, two weeks ago. We would have saved a lot of time.
>
>    
Ok, my error. But I must admit that the algorithm itself didn't take 
that much time, I invested much more in other optimizations.

> code completion window, so the search algorithms doesn't need to be the
> same.
>
> If you think that using two different algorithms may lead to usability
> issues, I'd like to see a concrete use case.
>
>    
The use case is to search for types or members. Both code completion and 
navigate to dialog can do that.
>> Now to the algorithms - how they work. First the navigate to dialog
>> algorithm. It matches a word, if the filter is a subsequence. For example:
>>
>> The filter 'strm' would match 'Stream', 'stringMatch', 'StrongTypMatch'
>> but also 'FirstStorm'.
>> It currently completly ignore scase - 'DBO' == 'dbo' and would match
>> 'dboField', 'DataBaseObject', 'DBOStuff' or 'OddNumberContainer'.
>>      
> That's wrong. The algorithm does not ignore case. It gives the correct
> result for that last case.
>
>    
'DBO' and 'dbo' both matches dboField. That is the case I ment - this is 
an important difference of the two. In fact both algorithms are somewhat 
the same - I'm sure both could simulate each other with 1-2 small 
changes, that's why I found it important to give some examples where 
they differ.
>> This makes sense for example when you have a term 'Autotools' and you
>> search for 'tools' this is matched - the other algorithm won't match this.
>> The plus side of this approach is that it gives you>many<  items in the
>> case you're not really sure what to look for.
>>      
> Getting too many items is not a problem. If you do a search in Google
> you get thousands or millions of results, is that a problem? no, because
> you know that Google is good at ranking, so in 99% of cases what are you
> looking for will be in the first results page. And in case you don't
> find it, you can keep browsing other pages. The Navigate To dialog works
> in the same way. It doesn't matter if it returns a lot of items as long
> as the best ones are shown at the top.
>    
The problem is than when I search for a 'string' I don't need viagra sex 
pills. And AFAIK we don't have currently very good ranking - we've only 
pattern based ranking. I've already read a bit about how we could 
achieve some intelligent learning like google does. This would require 
some bigger changes in the data structures we have (maybe something like 
a suggest tree would work). I would love improving the results we give - 
if we could find a ranking system that would help that the user gets in 
99% of the cases what he is looking for in the first 5 results it would 
be awesome.

This is an area we should put some research in :) ... I think we're 
pretty good with our pattern based ranking - but google is better.

> I'm ok about using this algorithm in code completion because the
> completion window is small and it is not sorted by rank, so unlike the
> Navigate dialog, getting less results is better.
>
>    
Ah ok, it sounded very different before, maybe I misunderstood 
sometehing? I prefer getting results fast - while code completion I 
barely need an overview of all available results. Reducing the noise in 
the code completion is one of my higher priorities for the next version 
(for example atm there are almost any keywords in the window - with 
better context recognition that number can be reduced + sometimes only a 
small number of items is needed - just showing types etc. ... there are 
many contexts that wait for an improvement).
> We are going to use the first algorithm for the Navigate dialog, and the
> second for code completion.
>
>    
I can live with that - I use the navigate to dialog much less than the 
code completion. (but it's my no. 1 tool for going to a specific location).

Regards
Mike