[MonoDevelop] Navigate to dialog item filter

[Lluis Sanchez Gual]

El dl 02 de 08 de 2010 a les 15:43 +0200, en/na Mike Krüger va escriure:
> 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,

It's not a matter of finding more matches, but about properly ranking
them, and suggesting the best match.

> 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 agree.

> 
> 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.

I'm ok with changing the algorithm if it is faster, but I don't want to
lose functionality.
> 
> > 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).

When typing in lowercase, the algorithm should consider that any letter
can potentially be a word start. Also, short matches should have
priority over longer matches. So 'dob' should match 'DatabaseObject'.

I'm OK about interpreting upper case letters as a forced word start,
although I never use that. If I want to look for DatabaseObjectBase it
is faster to type 'doba' than 'DOB'.

> Do you agree on these cases ? (I'm always open for ideas how to
> improve the matchding 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) 

I also think it is better to have a single algorithm (unless the most
correct algorithm is too slow for code completion, in which case it
would make sense to use a more simple but faster algorithm for code
completion only).

Lluis.