[MonoDevelop] Code completion matching - input needed

Mike Krüger mkrueger at novell.com
Tue Aug 10 17:15:45 EDT 2010


This represents my personal opinion:

I think it's wrong using the lane matcher - because:

1) It gives back too many items
2) It's slower (ok I admit that it has become quite fast compared to the 
one we shipped with 2.4)

.. The input we have files/types/members is >always< camel or pascal 
cased - and I'm thinking in that way when I filter items. I don't want 
some weird results because a misleading substring matches the word 
somehow. I want exact results and I want to get to the code completion 
result I want fast.
I use abbrevs and word jumps a lot. It's really nice to force word jumps 
with upper case letters. Once you get used to the prefix word matcher 
you'll enhance your typing speed a lot.

The last days I worked with the lange matcher had a negative impact on 
my workflow ... that's why I don't want this (not because I think my 
implementation is better or something stupid like that) ... I just want 
my old workflow back. The algorithm wasn't invented by me - it's the 
behavior R# has. I think that the guys at Jetbrains have done an 
incredible job at enhancing the productivity of developers - their 
completion filter is just a small but fine part of their product. I see 
the other approach as sub optimal compared to that.
Another point is - there is a difference in speeds ... it does matter if 
you wait for 200ms or 50ms ... the example input data is large ... but 
you can get that many ismatch requests in a project like monodevelop. 
The difference isn't as much as it is some weeks ago (lluis & I 
optimized the other algorithm) but I still think that we need a very, 
very good reason to use a slower algorithm.

Internally we can't decide which one we choose - maybe some of you 
noticed that there are quite a few changes in that area - mostly each 
developer commented out the other ones work. I'm in charge for the 
completion - theoretically but lluis as offical project manager decided 
that we use his approach (it fails still the unit test suite about 
completion btw.) ... and if we decide to stick with that I think that 
I'll make a little fork of monodevelop that just contains this small 
change for personal use - if some people have interrest in that I'll 
make it  public.
- yes the typing behavior is very important to me ... maybe one of the 
most important parts on monodevelop. I've many more features that'll 
affect the typing behavior in C# code in the future - I want to minimize 
the keystrokes we all need to do - producing more noise in the 
completion results is not helpful on that endevour.


More information about the Monodevelop-list mailing list