Improve link suggestions with fuzzy search fallbacks

Use case or problem

When using the link suggestion popup to create a link to an existing note, the current fuzzy search algorithm is slightly too restrictive. It produces zero results for some very reasonable attempts at a match.

For example:

  • Where's my music collection note about [[The Ramones
    does not match a note titled Ramones. (Did you know that’s the actual band name?)
  • Where's my recipe for [[how to cook spaghetti squash
    does not match note how to make spaghetti squash

Problem: the current fuzzy search algorithm requires a match for all search terms, with no fallback to a less restrictive search.

Drawbacks: If I’m certain that my desired note exists, I have to try to remember what else I may have titled it and try again. If I’m not certain it already exists I may create a redundant note, wasting time and cluttering my note collection.

Requiring a match for all search terms makes sense for Obsidian’s file search engine but not for link suggestion. File search happens in a search box where users are intentionally constructing boolean queries. Link suggestion happens in the context of natural language. It’s a similar but distinct UX case.

Proposed solution

If there’s no match for all search terms, fall back to a match on fewer search terms. Results with more matching search terms rank higher.

Secondarily, results with longer matching search terms rank higher. (This is an optional but probably useful optimization for ranking ‘substance’ words higher than words like the and as of etc…)

Related feature requests

This pairs very well with @ShaneNZ’s feature request for when you want to link a phrase you’ve already written. The link suggestion UX for that case is currently broken, i.e. there is no link suggestion.

6 Likes

Here’s my similar request for improvements to fuzzy searching in Quick Switcher and Link Suggestions.

(edit: fixed link)

Is there any way to disable case matching when searching? I dont typically want to have to get the uppercase first letters of titles correct to find them, but that seems to be required.

@dsteinbock have you noticed this?

Hmm, actually I’m not seeing case match being a requirement. Maybe I’m not understanding, or maybe you found a bug or an edge case. Can you give a specific example?