[MonoDevelop] Code completion matching - input needed
Lluis Sanchez Gual
slluis.devel at gmail.com
Wed Aug 11 06:53:47 EDT 2010
El dt 10 de 08 de 2010 a les 23:15 +0200, en/na Mike Krüger va escriure:
> 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
That's not true. Different projects and different languages may have
different conventions. The Mono coding guidelines explicitly state that
instance members should use underline as separator. C does not use camel
or pascal casing, yet we need to support the Navigate dialog and code
completion for it.
> 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
It's decided, but looks like you are unable to accept it.
> - 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.
That's not the right way of handling differences. I already told you. If
you have an usability problem file a bug report.
More information about the Monodevelop-list