Ralf Mattes rm@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 theuser 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.