fuzzy-match behavior when input doesn't match any suggestions

[aadcg]

It's reasonable to expect that a filtering mechanism returns a proper subset of suggestions when matching against input. In some cases that subset might even be the empty set.

However, fuzzy-match return all suggestions in some situations.

Example:

• Issue execute-command;
• Run (length (prompter:suggestions (current-source)));
• Set the input to something bogus, say "sklfjslkfjslfjsk";
• Run (length (prompter:suggestions (current-source)))

Both calls to (length (prompter:suggestions (current-source))) return the same value.

I find this behavior extremely strange.

CC @lansingthomas @jmercouris @Ambrevar @aartaka.

[Ambrevar]

I find it matches the expectation of "fuzziness".

You can tweak this behaviour by using delete-inexact-matches.

[aadcg]

I find it matches the expectation of "fuzziness".

The term "fuzzy matching" is sometimes (wrongly, in my opinion) used to mean "flex matching": "foo" matches according to regex ".*f.*o.*o.*". Our fuzzy matching goes by its correct meaning: assign a score to all suggestions and sort accordingly. But the concept of fuzzy matching doesn't require returning all suggestions in the order dictated by the score.

My point is that our default prompter:filter (coupled with the defaults of prompter:filter-preprocessor and prompter:filter-postprocessor) doesn't always narrow down to a proper subset of suggestions, and that may be confusing to users.

You can tweak this behaviour by using delete-inexact-matches.

Let's please focus on the defaults that are presented to the user. In the example presented in the original post, don't you think that delete-inexact-matches should have filtered a non-empty subset of the suggestions?

Note that I've edited my top post slightly.

[Ambrevar]

It depends how you think about it. You are taking the logical angle, but the current implementation follows a practical "do what I mean" angle: showing nothing in the prompt buffer is useless, because there is nothing to do then. So we'd rather display everything then so that the user can select suggestions and act upon them.

It would be clearer if we highlighted the matching parts in the suggestions. For instance with input "foo bar", suggestion "foo17" would have foo highlighted. In case of no match, suggestion "whatever" would have nothing highlighted, thus making immediately clear that the fuzzy-match didn't match anything.

What do you think?

[Ambrevar]

The missing highlight feature I'm talking about is referred to in atlas-engineer/prompter#32.

[aartaka]

I had encountered this behavior more than once, and I'm not sure it's the most intuitive. I myself would rather have an empty prompt than the full one with confusingly irrelevant matches.

[aadcg]

@Ambrevar I've now fully understood your perspective.

The point where I'm afraid we disagree is when you mention:

(...) showing nothing in the prompt buffer is useless, because there is nothing to do then.

I believe that empty suggestions would communicate: "there's a typo in your input" or "the thing you're looking for doesn't exist".

I believe this is in line with @aartaka's last comment.

[Ambrevar]

Yup, but if we had match highlighting, then we would also convey this information, since the first match would not have the input highlighted.

This is how Helm works.

[aadcg]

I agree that it would help convey the information, but I think that match highlighting is desirable regardless of the conclusion on the topic at hand. In short, I believe that even if we had match highlighting right now, it's still worth discussing this topic.

We can come back to this at a later time with @lansingthomas and @jmercouris.

[Ambrevar]

In any case, I don't have a strong opinion about this. If you all think it'd be better to hide non-matching results, no problem.

[lansingthomas]

You dudes already know this but I will say it anyway.

If a system returns an empty value -- there should be a rendered indication. It is important because it helps users problem solve. A clear status indicator anywhere (message buffer or wherever) lets the user know that the input was appropriate, even though the search returns nothing useful.

we could have something fun when this happens

• even our powerful fuzzy search has nothing for "sklfjslkfjslfjsk"

Or something simple that still communicates that the system is working

• no result

Maybe someone can explain match highlighting and the rest of this context on our next call.

[aadcg]

Maybe someone can explain match highlighting

The idea is to visually display the matching substring in the suggestions. You can find an example below (from another program) - matching "buffer" against a bunch of suggestions. In Nyxt we're lacking this feature. In our case, "buffer" would not be highlighted in the suggestions displayed by the prompt buffer.