doesn't always list the closest matching first

I had a comment about search quality when reviewing part of the hud code[1]. Will paste it here again so that it doesn't get lost:

imo, sorting by summing the relative usage and distance isn't a very good
strategy, as both usages and distances will tend to only have few very
small and many very large values, which is always tricky when dealing
with percentages.

Somewhat exaggerated example: Usage count for "open" and "save" is 10 each.
I type "blur" (which is a perfect match) for the first time:

       distance usage total (as in usage_sort())
blur 0 0 % 0 0 % 100 %
open 4 50 % 10 50 % 100 %
save 4 50 % 10 50 % 100 %

Ranking those 3 the same is surely not what we want?

[1] https://code.launchpad.net/~ted/indicator-appmenu/hud/+merge/89905/comments/194449

@lars, I think that's a different bug #923999

I added a test case to the distance suite (in the attached branch) and that fails as well. Confirming.

This bug was fixed in the package indicator-appmenu - 0.3.90-0ubuntu2

---------------
indicator-appmenu (0.3.90-0ubuntu2) precise; urgency=low

  * Backport upstream work for better matching of utf8 strings (lp: #930065)
 -- Sebastien Bacher <email address hidden> Tue, 14 Feb 2012 17:58:13 +0100