[slime-devel] Re: [PATCH] Fuzzy Completion cleanup

[Tobias C. Rittweiler]

Ralf Mattes <rm at mh-freiburg.de> writes:

> On Mon, 26 Feb 2007 21:13:24 +0100, Tobias C. Rittweiler wrote:
>
> > There are two user visible changes:
> >
> >  ...
> >
> >  ii) the symbols in the *Fuzzy Completions* are now sorted
> >      alphabetically before sorted by their score. From my ChangeLog
> >      entry:
> > 
>
> This sounds wrong for the 'normal' case: isn't the whole point of
> 'fuzzyness' lost. When, actually, would two symbols be sorted equal
> alphabetically so that scoring would kick in?

Hi Ralf,

I'm not sure that I understand what you mean exactly here. The
completions are sorted alphabetically first, and then sorted by
_their score_ afterwards via STABLE-SORT.

It's extemely unlikely that two symbols will be get the same fuzzy score
in the first place ([*]) -- and if two coincidentally do, they'll be
presented alphabetically rather than in random order.


[*] The fuzzy completion code looks for symbols and packages fuzzily
    matching the input string. I changed the way of how packages are
    matched very slightly: Prior to my patch, a colon was appended first
    to a package name before its fuzzy score is computed, my patch
    appends the colon afterwards. Hence the score for packages is a bit
    higher now than before because, e.g., "ASDF" instead of "ASDF:" is
    used when matching against "ASD".

    Now let's say we're in a package that has got the symbol 'ASDF
    interned and you try to fuzzy-complete "ASD". Then the symbol-name
    of 'ASDF is found to be a good match as well as the package-name
    "ASDF". Priorly, the fuzzy score for the symbol 'ASDF has been a bit
    better than the package name, because the latter's score is actually
    that of "ASDF:" -- after my patch, they both have the same
    score. (The package one will still be presented as "ASDF:", though!)

    *However*, because the completions are sorted alphabetically,
     "ASDF:" will be presented after "ASDF" even after my patch.

    (The behaviour can easily be adapted to the old behaviour; I didn't
    bother, though, because, on one hand, I wasn't quite convinced that
    it was really right in the first place (more a consequence of how
    the relevant code was organized), and on the other hand, it should
    not make a real difference to the user.)



> >     Affects especially the list of all possible completions when the
> > 	user hits fuzzy-completion on an empty string within Emacs; 
>
> Sounds like you optimize for the mindless user ...

No, not at all. :) It's not just useful for just the empty string
(i.e. pressing tab tab on the REPL), but for looking at all symbols
exported from a package, like "asdf:tab tab". This way, it's also a
cheap alternative to C-c C-d p (SLIME-APROPOS-PACKAGES), because you can
use isearch on that buffer. 


> >     also makes the potential limitness of the listed completions 
> >     clearer to the end user of SLIME.
>
>
> I thought our 'end users' would be slightly smarter than the average ;-)

I don't really know this for sure, but the limit might have been
introduced after fuzzy-complete turned out to be too slow. Anyway,
I didn't know that there was a limit before yesterday. :)


Thanks for the feedback,

  -T.