[MonoDevelop] Code completion matching - input needed

[Lluis Sanchez Gual]

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

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.

Lluis.