[MonoDevelop] Navigate to dialog item filter

[Mike Krüger]

Hi
> The old algorithm is a bit slower, but it gives better search results.
> For example, try looking for 'ccommand'. The list you get using the old
> algorithm makes much more sense to me than what you get in the new one.
>
>    
Some wouldn't be the problem it's only a bit - it'. Yes the old one 
finds more matches - I know that,
But I want to know from the users which search cases should be matched - 
I just don't believe that the substring matching in the navigate to 
dialog should be different than that in the code completion.

I took the code completion algorithm as a start because of the speed.

For MD alone we match up to 141702 items - that's on my machine:
8623ms vs 128ms

I've implemented some caching algorithm that leaves us to match 90400 
items. Thats still roughly 5200ms  vs 84ms on my system - thats not a 
bit slower - thats magnitudes slower. I tested this with the stand alone 
version & took the MD numbers of items, it's hard to tell how long it 
takes in monodevelop - could be more/could be less - but it's another 
user experience when changing the algorithm. Thats why I've came up with 
this again.

> Also, the new algorithm can't handle some queries. For example, if I try
> to look for CustomCommandCollection
>   using the strings 'comcoll',
> 'cuscoll
> ' or even 'commandcollection' I don't get any result.
>
> Those issues should be fixed before switching to the new algorithm.
>
>    
This are two examples I would value as bug - I've not thought about that 
case. They should match for the code completion as well.

I added them to the code completion bug unit tests. To match them I've 
taken the other algorithm and used some optimizations and now it runs 
the 90k items in around 2200ms - still there is room for improvement.
But by changing to the other algorithm 2 unit tests failed. (another 
reason to use one matching subsytem)

The new matcher  matches "AbCdEf" when a filter "bC" is given. And it 
matches "DatabaseObject" when "DOB" is given - the latter may match (I 
don't think it should - upper case should always force a word jump IMHO) 
- but the bug report was about
"DatabaseObject" vs. "DatabaseObjectBase"  - in that case 
"DatabaseObjectBase" should be selected (however with "dob", "Dob" or 
"DOb" the "DatabaseObject" is the better match).

Do you agree on these cases ? (I'm always open for ideas how to improve 
the matching even more - the matching logic is an important part of the IDE)

I see no reason for using two algorithms, using two would mean:
A) We never find all those issues
B) Monodevelop behaves incosistent (different filters for code 
completion/navigation dialog)

If anyone has interrest in playing around how the subword matcher works 
it's all in CompletionMatcher.cs - it's an easy class to change.

Regards
Mike

> Lluis.
>
> El dg 01 de 08 de 2010 a les 18:21 +0200, en/na Mike Krüger va escriure:
>    
>> Hi
>>
>> I changed the navigate to dialog item filter - I had it a few versions
>> before - but then reverted it to the 'old' navigate to type/file filter.
>> (nobody recognized afaik)
>> But after that the navigate to dialog was very slow when filtering large
>> projects like the monodevelop one - (but nobody recognized that too).
>>
>> Now I've changed it back to the completion filter - the code completion
>> uses a very easy greedy algorithm - the navigate to filter was more
>> complicated. (but I think it's more a matter of taste which one is more
>> correct)
>>
>> I attached a small test file which compares the speed of the two
>> algorithms. Most of you know the filter from code completion - but I
>> want some feedback from our users about that issue.
>>
>> I prefer the code completion filter alone for consistency reasons - I
>> like how it behaves&  how to search items with that. It should behave
>> like the R# filter.
>>
>> /Discuss
>> Mike
>> _______________________________________________
>> Monodevelop-list mailing list
>> Monodevelop-list at lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/monodevelop-list
>>      
>
>    

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/monodevelop-list/attachments/20100802/63b24af8/attachment-0001.html