fuzzy search was a great improvement but it came with its own flaws.
now even if you type the exact same name of note while linking, it won’t show up in the first place or at least the first instance of the search. I would have to scroll through the whole list to find it
image to support my argument
It is probably easy to solve, just prioritizing the words that contain the letters together.
When I make a link with [[ and start typing the filename, Obsidian lists the ‘fuzzy’/incomplete matches first.
That should not happen. When I type part of the filename, I specifically look for that part of the filename. So exact matches should always come first.
Here’s an example situation:
In this situation, the exact file I was looking for appeared halfway through the list and had didn’t have the right bold font to make it stand out:
(I searched the forum but couldn’t find a similar request. If there’s one already let me know!)
I raised a related point here:
https://forum.obsidian.md/t/the-role-of-anticipating-autocompletion-in-getting-the-full-benefits-of-bidirectional-linking/
Pretty sure this is fixed in 0.8.2 (if it wasn’t in 0.8.1), so it will be public soon!
I don’t think so. The release notes for 0.8.1 talk about handling the link autocomplete when it involves file paths:
Link auto-complete and quick switcher would match the file name as a priority, instead of always matching the full path. This should improve the match ordering for searcher that contain characters in the parent folder, such as searching for “task” in “test/task.md” which previously matched “[t]est/t[ask]” instead of “test/[task]”.
For your Vault that works better since you have a ‘Notes’ subfolder. But my Vault doesn’t have notes in subfolders so the improvement doesn’t apply to me. 
(There’s no mention of link autocomplete changes in 0.8.2.)
On 0.8.1 I still get fuzzy matches before exact ones:
@JkNML I’m attempting to recreate your example, and in 0.82 is appears to be working. It matches 070040 first, before matching fuzzy matches.
Also you mentioned something about folders being significant, so I moved these test notes into my root Vault. Still seems to work.
That’s very good news. Thanks for taking the time to test it on your end. That’s nice.
I’m still on 0.8.1 so can’t confirm it 100%, but will once I also get that version.
Unfortunately it didn’t seem to change on 0.8.2.
On 0.8.2 I get when typing 070040:
The exact match appears roughly halfway through the list:
(By the way, this reply of mine is just a follow-up. If there wasn’t a question about whether 0.8.2 fixed it I wouldn’t post again since I’m quite a patient person actually. )
An improvement to the fuzzy search algorithm is planned (No ETAs though!)
Ah. I guess with my test, I had the exact match at the front of the name. And in your actual usage, the exact match is part-way through the filename.
An improved algorithm will be present in 0.8.6
