Odd fuzzy matching in command palette

[reagle]

I love the command palette! 🙂

Why is it when I type "open" and "open file" open-file is not suggested -- but it is for "file"?

[midichef]

For "open", there are just too many good matches for open-file to be seen. By default, the command palette is set to show at most 10 items. For "file", there are fewer good matches, so open-file ranks high enough for you to see it.

You can allow a longer palette by running vd as vd --disp-cmdpal-max=40, or by putting options.disp_cmdpal_max=40 in your .visidatarc. Then if you search for "open", open-file shows up as item number 36.

[reagle]

@midichef thanks for the tip on showing more options.

Even so, failing to match "open file" to open-file does seem odd to me. Similarly, "fileo" has open-file as the first candidate (good) but "fileop", adding the letter "p", drops open-file from the top 10 candidates while items such as "breakpoint" and "cancel-all" are included.

[geekscrapy]

I would like to see multiple matches (like open) be ordered by their order in history. For example if you used "open-file" a lot, entering "open" would pop "open-file" quite near the top.
However, that does make the list more dynamic and therefore unpredictable. This means you'd always need to check the index before selecting.

I prefer predictably though.... For which I have no good solution 😅

[midichef]

@reagle
You were correct to note how odd this behavior was. It turns out you were pointing out hidden bugs in the command palette. I wish I'd caught on at the time. @aborruso pointed out similar oddities, that led to a fix. I can now explain what was happening.

For "open" not ranking open-file, the reason was that matches were case-sensitive. "open" (lowercase) failed match the uppercase description for open-file: Open file or URL (with an uppercase O). So all the other matches that had lowercase "open" in the description, ranked higher. This case-matching bug has been fixed by #2658.

For "open file" not matching "open file", there was an error handling matches for space-separated patterns. Now fixed by #2646.

For "fileo" matching but "fileop" not, I believe that is working as intended. The fuzzy match algorithm tries to match each group of characters in order. If you do want to match out of order, create multiple groups of characters by using a space: "file open".

But the behavior should probably be changed a bit. When no match can be found for all the characters in "fileop", the matcher has a couple of options that seem reasonable to me. It could fall back on trying to match characters out of order, or show the last successful match pattern (in this case, show the match for "fileo"). If you want to create a separate issue for that, please do.