[MonoDevelop] Navigate to dialog item filter
Lluis Sanchez Gual
slluis.devel at gmail.com
Mon Aug 2 10:41:32 EDT 2010
El dl 02 de 08 de 2010 a les 15:43 +0200, en/na Mike Krüger va escriure:
> > 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 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
> > 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
More information about the Monodevelop-list