[MonoDevelop] Code completion matching - input needed
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