A different approach to fuzzy finding | Hacker News Reader

A different approach to fuzzy finding

nathancraddock.com

73 pointstodsacerdoti11 comments

> Notice that both fzf and fzy ranked source/blender/makesdna/DNA_fileglobal_types.h higher than GNUMakefile. I believe this is because /make and _file in that path are on word boundaries and are ranked higher than UMakefile that is not on a word boundary.

The reason for prioritizing word boundaries is so that you can type "sln" to match "SomeLongName". So while you are improving one use case you are probably breaking another one. I'm not sure how VSCode ranks GNUmakefile first, maybe they prioritize exact substring matches. It's still a heuristic that can fail. The ugly part is that it's not part of the "best match" algorithm that finds a global optimum.

> It first attempts a match on the filename. If there is no match, it retries on the full candidate string

Kakoune does the same, see https://github.com/mawww/kakoune/blob/019fbc5439ad884f172c32...

> Strict path matching means that the path segments of the query token cannot overlap between path segments in the candidate.

nice

> Kakoune does the same

Great! I’m glad I’m not the only one to have thought of this simple idea :)

This is a great post! Fuzzy finders are really useful, and we are always trying to find a tool that will “read our mind” and give us the thing we are looking for as quick as possible. One thing that I found really useful is sorting based on past searches. If I search for the same type of files commonly (like make files) then the sorting will put those higher. Often times I don’t even need to type anything because the file I want it the first one!

Looks like the author doesn't know about FZF's different search syntaxes https://github.com/junegunn/fzf#search-syntax

If they had left quoted the word makefile, GNUmakefile would have been the first result.

Author here! I’m aware of the FZF search syntaxes. They are very useful! I designed zf to be a small tool that worked a bit better for me by default without special syntaxes.

Have you considered submitting this idea as a patch for fzf (like with a flag to switch syntax)? fzf author seems fairly strict/holding back about what goes in and what not, but it seems worth an attempt: thing is fzf can do a lot, is pretty well architected, many features are really neat, and it seems less work to patch it than to start from scratch.

No I hadn't considered that. I wouldn't be against my "zf algorithm" being ported to other tools though. But when I first had the idea for zf I had just learned Zig and it seemed like the perfect way to practice with my new language.

Would that have been the case even if there was a directory along the path called “makefile”? Or would the paths with that directory get ranked higher because the matches string occurs earlier in the path?

Or a directory called "remakefiletsrecipe"

"Fuzzy finding is most commonly used to filter files"

Maybe there's some nuance of "fuzzy finding" as a phrase that I'm missing, but that seems questionable. I'd agree with "commonly used", but not "most commonly used".

Aren't things like address matching "fuzzy finding"?

Edit: Perhaps "fuzzing finding" is analogous to "command line based fuzzy finding", in which case it makes more sense to me.

What I found lacking with fuzzy fingers was the shell integration. I typed “vim src/“ into the shell and then hit the key that summons the fuzzy finder. I expected it to show me files in the src directory, but it didn’t.

Are there other integrations that do this?

I don’t quite remember what I tried, maybe fzf and skim?

Reply on news.ycombinator.com