-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Some questionable rankings of various matches #63
Comments
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
The basename gets a boost. ".stumpwmrc" is a basename. ".stump/" gets a
The workflow with a big collection is to specify abbreviation and prefix
The issue is the breaking of works is based on whitespace, so the "g" in
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 |
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? |
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:
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 |
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). |
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.
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.
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?
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!
The text was updated successfully, but these errors were encountered: