Some questionable rankings of various matches
scottjad opened this issue · 13 comments
Hi, I just tried out flx and flx-ido a few days ago. I'm happy to hear that the fontification of flex matches I did in ido-hacks inspired you.
Some of the match rankings don't seem optimal in my use and I wanted to run a few examples by you just to confirm that overall you think the current rankings are best.
(completing-read "" '(".stumpwmrc" ".stump/") nil nil ".stump")
I'd expect .stump/ to win. I think this is the most important of the examples, since I think exact matches on directory names should match without a /.
Perhaps the number of characters in a candidate that don't match should be counted against it? I'm not sure.
(completing-read "" '("amusic" "texinfo-all-menus-update") nil nil "amu")
I'd expect amusic to win. I think you should prioritize prefix matches a bit more over first letter matches, but this one is a bit more subjective, and perhaps my use hasn't been diverse enough to recognize the benefits of the current settings. What are some examples of things you complete where you really want prefix to lose to first letter matches?
(completing-read "" '("*Group*" "*Customize Group: Flx*") nil nil "group")
I'd expect Group to win here. I think matches near the beginning should be preferred, if they aren't already, and perhaps omitting punctuation shouldn't count against a match.
Love what you've done and I look forward to using it more!
(completing-read "" '("amusic" "texinfo-all-menus-update") nil nil "amu")
I'd expect amusic to win. I think you should prioritize prefix matches a bit more over first letter matches, but this one is a bit more subjective,
It appears to me now that prefix wins over first word letter at four characters. I guess that's understandable, I think I don't have enough experience with long filenames to appreciate the current setting. Perhaps it should be configurable without having to redefine flx-score.
On Sun, Sep 21, 2014 at 5:42 AM, Scott Jaderholm notifications@github.com
wrote:
(completing-read "" '(".stumpwmrc" ".stump/") nil nil ".stump")
I'd expect .stump/ to win. I think this is the most important of the
examples, since I think exact matches on directory names should match
without a /.
The basename gets a boost. ".stumpwmrc" is a basename. ".stump/" gets a
basename of "". This should be corrected.
Perhaps the number of characters in a candidate that don't match should be
counted against it? I'm not sure.(completing-read "" '("amusic" "texinfo-all-menus-update") nil nil "amu")
I'd expect amusic to win. I think you should prioritize prefix matches a
bit more over first letter matches, but this one is a bit more subjective,
and perhaps my use hasn't been diverse enough to recognize the benefits of
the current settings. What are some examples of things you complete where
you really want prefix to lose to first letter matches?
The workflow with a big collection is to specify abbreviation and prefix
together. E.g. heexpreld to find "helm-eval-expression-with-eldoc".
(completing-read "" '("Group" "Customize Group: Flx") nil nil "group")
I'd expect Group to win here. I think matches near the beginning should
be preferred, if they aren't already, and perhaps omitting punctuation
shouldn't count against a match.
The issue is the breaking of works is based on whitespace, so the "g" in
"Group" does not get a boost for being the beginning of a word. This
maybe should be tuned.
Love what you've done and I look forward to using it more!
—
Reply to this email directly or view it on GitHub
#63.
Le
In case you're curious about scoring, I've made a version of the helm demo with your wordlist. This shows the scoring interactively -- https://github.com/lewang/flx/tree/scottjad-demo .
Just run flx-helm-demo .
I also stumble over the sorting — roughly once per day I need to keep typing and typing until ido gives me the match, even though it is just 2-3 letters different from what I typed. This is most visible when trying to match org-mode commands using amx (i.e. try to match org-clock-report).
Would it be viable to add minimal string-distance calculation so flx prefers not just short full matches but also almost equal matches?
org-clock-report is the first match for ocr here.
flx is already quite taxing on CPU and memory resources as it is, there should be a very good reason for adding more heuristics.
I would not have thought of searching for "ocr". I searched for org-clock and did not get it.
This shows that you don't use flx effectively. A good heuristic when looking for Emacs commands (M-x) is to start typing the initials of the words that make that command and if this does not put what you search for at the beginning then keep typing the rest of the letters of the last word. Do it slowly and observe how flx reorders the candidates.
Eventually, for commands like org's that have long keybindings (3 or more letters with modifiers), you will invoke the command faster with ido+flx than using its associated keybinding. Furthermore, it is easy to remember, more discoverable and more ergonomic too.
If I were more fluent in English, I'll write an article explaining all this for attracting more users. flx has not the popularity it deserves.
I might not use flx effectively, no. I’m using it as I expected it to work: Typing what I remember of the commands. One reason seems to be that I often don’t know the order of the words in a command. So I’m typing "org-clock" in the hopes that it gives me all commands with org-clock, because it might just be "org-clocktable" or "org-clock-report-run" or "org-run-clock-report".
Do you see a way to make flx more efficient at discovering the correct command name?
I think the best thing you can do to spread flx is to create a simple youtube video.
Since your english is not great, just do an org-mode presentation with music as background, similar to this: https://www.youtube.com/watch?v=U8a8em-4m0w (but much shorter: 1:30 should be perfect to show "flx matching gets your command much faster" "standard ido-flex as comparison" "same commands found much faster with flx" "try flx" (with the URL and package name at the end)).
Besides: flx does not feel slow for me, at least not on the machine at work (but that has 64 GiB of memory).
I don’t have my optimized setup at hand right now, but this hit me just now with regular ido flex matching.
How does flx cope if you have two files: One emissions-tokyo.tex and one emissions-tokyo-auxilliary.tex — will the shorter be the first match?
I now tested this:
- Setup:
touch emissions-tokyo.tex emissions-tokyo-auxilliary.tex - Now try opening the file with C-x C-f (naturally using ido-flx).
I found no way to get emissions-tokyo.tex to be the first match.
Another part I just stumbled over is searching all functions (with C-h f) for ones which start with user: when I type "username" I find lots of matches, but user-login-name is not in front. If I instead search for "user-", I don’t see user-login-name at all.
However typing "user-login" nicely gives user-login-name and vc-user-login-name — in that order, which is the order I’d expect.
(I use Ido-Everywhere and Ido-Ubiquitous to get ido-completion almost everywhere)
One thing flx does not is mind-reading, which is the only method for doing the Right Thing.
Saying "I searched for this and the suggestions didn't fit my expectations" is hardly helpful. Please study how flx works and then come back with improved heuristics, an actual algorithm that can be translated to code (or better, show the actual code) explaining why your method is preferable.
BTW, if I had to find user-login-name, I'll type uln. If you want a completion system focused to substrings, there are some of them. Emacs' default mechanism is one option, although a bit simplistic.
I’m not giving the examples to attack flx, but to provide data which could be used to check algorithms, for example the different options suggested in other issues. One suggestion I gave here was string-distance. Another in one of the other issues was priorizing shorter names.
I’m looking for completion which just works™, and flx is almost there.
I think I now see the reason for my main problem with the matching: When searching for org-agenda I could not get org-agenda to the front. When I hit TAB-TAB, I saw why: org-agenda is marked here as "org-agenda (C-c a)", and that is what flx tries to match against.
This is due to using the amx package which integrates completion with M-x with completion.
Disabling the option amx-show-key-bindings removes the keybinding info which significantly improves the matching when using flx (because those are keys I don’t actually want to match against, but which amx adds as information).